AI across every department — one pipeline, many jobs¶

Status: plan, being written 2026-09-13. Companion to task-board, which is where the work lands, and roles-and-skills, which is where the permissions come from. Tooling research is folded in below as it arrives.

The one idea¶

Do not build twenty AI features. Build one pipeline and add job classes to it.

Every useful thing an AI does in this shop has the same shape: it reads something, it proposes a change, a person reviews it item by item, and only then does it land. That is already the contract the assistant follows and the one task-board specifies for the proposal report. It should be the only way an AI changes anything here, in any department, forever.

a trigger  →  a job class  →  a bounded agent run in the sandbox
           →  a proposal report (file + email)
           →  per-item human review
           →  apply through allow-listed actions
           →  an outcome report and an audit trail

Triggers differ (a button on a task, a schedule, an inbound email, a failing audit check). Job classes differ (draft descriptions, parse a quote, cluster RMA causes). The middle never differs. Adding a department's next capability is then a day's work — a tool, a prompt, a review renderer — rather than a new system with its own way of being wrong.

What this buys: one place where cost is capped, one place where refusals are enforced, one audit trail, one thing to test, one thing to explain in an SOP. What it costs: the first job class carries the cost of the pipeline. That is already being paid by the task board's AI handoff, which is why that phase is worth doing properly rather than quickly.

The rules, which do not bend per department¶

It proposes; a person disposes. No AI writes to production directly. Ever. No exceptions for "low risk" classes — the exception is how the habit dies.
Per-item review, no approve-all. Established in task-board; it applies to every job class, not just the task ones.
An unknown job is refused out loud. An unrecognised request is not an invitation to improvise. The refusal says what it would have needed.
It never closes its own work. The machine does not grade its own homework.
Scoped credentials, not scoped prompts. Each department's runs use that department's ERP token, so the guarantee is enforced by a 403 and not by a paragraph. This is already true of the assistant and stays true here.
Every run is costed and capped. Dollars per run, per department, per month, against the existing budget. A runaway job hits a wall, not a bill.
It says what it does not know. A job that cannot reach a confident answer returns "a person has to do this, because…", which is a successful outcome and not a failure.

Where the value probably is, before the research lands¶

My prior, to be corrected by the tooling research rather than replace it. The pattern across all six departments is the same: the AI is good at turning unstructured input into a structured draft, and bad at deciding anything. So the wins cluster where the shop currently retypes something from a PDF, an email or a photograph.

Engineering — datasheet to part parameters; a design-review checklist run against a schematic; library conformance. Not: designing anything.
Purchasing — a supplier quote PDF or an order acknowledgement email into structured lines; a BOM sourcing pass that flags single-source and end-of-life risk. Not: choosing the supplier.
Production — work instructions drafted from a BOM and a placement file; a test log parsed into pass/fail with the failing measurement named. Not: judging a solder joint from a photo, which is the demo that always impresses and never holds up.
Sales — an incoming RFQ, however it arrives, turned into a draft quote with the parts matched to real IPNs; follow-up email drafts. Not: pricing.
Finance — a receipt or a bill into a coded ledger entry; a plain-English read of the month. Not: anything that is filed with a government.
Quality — RMA and feedback text clustered into recurring causes; a CAPA drafted from a nonconformance; SOP gap analysis against what the audit actually finds. Not: deciding whether a batch ships.

Tooling research, filtered (2026-09-13)¶

Commissioned a survey of free and open-source tooling per department. It came back broad and over-indexed on ERP suites, so the useful output is mostly the rejections. Recorded here so nobody re-proposes them in six months.

Rejected, with reasons¶

Proposed	Verdict
ERPNext as the backbone (its top recommendation)	No. We run InvenTree, which already does parts, BOMs, stock, POs, sales orders, builds and invoicing, with our templates, our SOPs and our tokens built on it. Swapping ERPs is a year of pain to arrive where we are
Part-DB parts database	No. It is InvenTree's job. A second parts registry is the drift problem again, in the one place we can least afford it
Octopart / Nexar API	No. It is paid now, and we already hold DigiKey and Mouser keys that give price, stock and lifecycle for free. Hard Rule 2
SiliconExpert lifecycle feed	No. Commercial. Revisit only if a customer contract demands formal obsolescence reporting
Mayan EDMS / Alfresco for document control	No. Git plus MkDocs already version every SOP with history and an audit trail, and InvenTree holds part attachments. Adding a Java ECM to this server for two people is the opposite of Hard Rule 1
SuiteCRM / Odoo / EspoCRM	Not yet. A CRM means a second customer registry beside InvenTree's. The real gap it points at is quote tracking — see below, and the answer is cheaper
Autonomous visual defect detection	No, and not soon. Needs hundreds of labelled failures per defect type. It is the demo that always impresses and never holds up

Worth having, and mostly small¶

The genuinely valuable items are in the KiCad ecosystem, which the survey largely missed. Each needs a verification pass before adoption — noted, not assumed:

kicad-cli in CI on the EmbeddedEra/KiCad repo. Headless ERC, DRC, gerber export and BOM on every push. Turns "did we run the checks" from a habit into a fact, and gives SOP-008 something machine-checkable. Highest-value engineering item on the list.
InteractiveHtmlBom — a self-contained HTML BOM with click-to-highlight placement. This is a production tool more than an engineering one: it is what you actually want on a tablet while populating a board, and it costs nothing to generate.
KiCanvas — the embeddable web viewer for KiCad schematics and boards Angel asked for months ago. Viewing only, no install, drops straight into an internal page.
KiKit — panelisation. Relevant because the shop already panelises twelve boards three up and tracks the panels by hand.
Free fab-partner DFM review (JLC, PCBWay gerber viewers) — not a tool to install, a step to add to SOP-008 before release. Free second opinion on manufacturability.
Quote tracking without a CRM. Quotes are genuinely untracked today, and that is a real hole. But we just adopted a kanban: a Sales pipeline project in Kanboard — enquiry, quoted, won, lost — is a pipeline for zero new software. Revisit a real CRM when there are enough live opportunities that a board stops fitting.
Frappe Books (MIT, double-entry, self-hostable) is the one credible answer to the still-open accounting question, and it is worth an evaluation. Caveat first: whatever we choose has to be something the CPA will accept an export from, so the CPA's opinion comes before the software choice, not after.

Job classes per department¶

The pipeline above, filled in. Each line is a candidate job class; none are built.

Engineering — datasheet PDF into part parameters; DRC and ERC output triaged into "must fix / accept / rule is wrong"; a house design-review checklist run against a board. Refuses: generating circuits, routing, and suggesting substitute parts — the last one looks safest and is the most dangerous, because a part that matches on paper fails on derating and pin function.

Purchasing — a supplier quote PDF or order acknowledgement email into structured lines; a nightly lifecycle and price watch over the BOMs we actually build, using the DigiKey and Mouser keys within their daily budget, raising a task when a part goes NRND or a price moves sharply; a single-source risk pass across active BOMs. Refuses: choosing the supplier, negotiating, and picking a cheaper alternate.

Production — work instructions drafted from a BOM and placement file, for a person to correct; test logs parsed into pass/fail with the failing measurement named; defect notes clustered into recurring modes. Refuses: judging a joint from a photograph, and reordering assembly steps.

Sales — an inbound RFQ, however it arrives, into a draft quote with parts matched to real IPNs and a complexity score against past builds; follow-up drafts for quotes gone quiet. Refuses: pricing, and rejecting an enquiry.

Finance — a receipt or supplier bill into a coded entry; invoice ageing into drafted chasers; a plain-English read of the month. Refuses: anything filed with a government, and anything that sounds like tax strategy.

Quality — RMA and feedback text clustered into failure modes with a Pareto; a supplier scorecard assembled from nonconformances and on-time delivery; a CAPA drafted from a nonconformance; audit evidence pre-filled for a person to tick. Refuses: closing a CAPA, and deciding whether a batch ships.

A network of department agents, and one administrator¶

Angel's picture: someone in Quality says "I want to amend this SOP, because…", tells their department's AI, and that AI works it up and takes it to an administrator AI that agrees, disagrees, or gives direction. Agents specialised per department, reporting to a brain.

That is a good instinct and it needs one correction and one substitution to be safe.

Two layers, one definition¶

There are already two different kinds of agent here, and it is worth not confusing them:

Build-time agents (~/Notes/rules/agents/) — the ones Claude Code hands work to while building the shop. Six now exist, one per department, each carrying its SOPs, its systems, its settled decisions and its refusals.
Runtime agents (~/Notes/skills/<dept>/SKILL.md) — the ones people talk to at chat.embeddedera.com. Five exist today.

They should be generated from one department definition — departments.yml plus the department's SOP list — so a rule written once appears in both. Two hand-maintained descriptions of the same department is the drift problem again.

The correction: a star, not a mesh¶

Agents must not chat freely with each other. Free-form agent-to-agent conversation loops, amplifies confident nonsense, multiplies cost invisibly, and lets text injected in one place travel everywhere. Every path goes spoke → administrator → human, and the administrator is one hop, not a committee.

The substitution: the task register is the message bus¶

Agents do not message each other. They hand each other work items in the task register, which we are already building. A handoff is a task with a department, an owner, a proposal attached and a state.

This is the whole trick. No new protocol, no queue to run, nothing to debug at 2am. Every exchange is visible to people in the same board they already read, a stalled handoff shows up as an overdue task rather than a lost message, and the audit trail is the one we already keep.

What the administrator agent is, and is not¶

It is not an approver. A machine agreeing with a machine is not an approval, and building it that way rebuilds "the machine grades its own homework" at company scale. Its job is triage against the rules, then routing:

Does this duplicate an existing SOP instead of cross-referencing it?
Does it name a person where it should name a role?
Is the version bumped and the revision row added?
Does it weaken or delete an audit check — and if so, is that argued or just convenient?
Which department actually owns this, and does it conflict with a settled decision?

Its outputs are exactly three: return with specific gaps, route to the owning department, or advance to a named person for sign-off. It never applies a change, and it holds no more write authority than any spoke — more read, not more power. It cannot grant permissions, least of all its own.

Worked example, Angel's own¶

Quality asks their agent to amend SOP-006 and says why.
The quality agent drafts it: version bump, revision-history row, cross-references instead of restatement, roles instead of names, and any audit checks the change implies. It runs sop-audit against the draft in the sandbox.
It files a task for the SOP's owning department with the proposal report attached — the same per-item review format as everything else.
The administrator agent triages against the list above and either returns it with gaps named, or advances it.
A person signs off. sop-deploy publishes. Nothing reached the live SOP without a human saying yes.

The guard rails this network needs¶

Hop limit. Three hops, then it goes to a person regardless. An item may not return to an agent that has already handled it without a human in between.
A cost ceiling per item, on top of the monthly cap. A conversation between machines is a way to spend money quickly.
Untrusted content stays untrusted at every hop. Text from a customer email, a supplier PDF or a guest's feedback is quoted as data and labelled, never followed as instruction — and that label must survive being passed along, which is exactly what a mesh would break.
Authority is the token, not the prompt. Each agent acts with its department's ERP token. What it may not do returns a 403, not an apology.
Every hop writes an event, so "who decided this" has an answer that is not "the AI".

Prerequisite¶

Quality is a function, not a department — settled in roles-and-skills on 2026-09-13 after checking RBAC practice and what ISO 9001:2015 actually requires. It stays inside Administration's bundle and gets its own function tags, so the quality agent acts on the quality functions rather than needing a department invented for it. The registry change (departments become bundles of functions) is the prerequisite, and it is small.

Ranked: the five worth doing first¶

~~An intake path for unstructured input.~~ Built 2026-09-14 — home.embeddedera.com/intake. Photograph a receipt, quote, acknowledgement, RFQ or packing slip and it becomes a task for the department that deals with it, file attached, provenance in task metadata. Not email, deliberately: embeddedera.com's MX belongs to Google Workspace and Cloudflare Email Routing would have to take those records over — losing the shop's email to gain an inbox. Email intake stays an open question; a camera page is the better door for anything you are holding. It does not read the document: that is the job class, and it now has something to read.
kicad-cli checks in CI, feeding failures into the task register. Cheap, deterministic, no AI involved, and it makes SOP-008 real.
The lifecycle and price watch, on keys we already hold, raising tasks. This is the one that quietly saves a build six months from now.
InteractiveHtmlBom and KiCanvas, because they are nearly free and Production and review both get better the day they land.
Settle accounting — CPA first, then evaluate Frappe Books. It is the only item here blocking a whole department.

Note what is not in the top five: every large system the survey recommended. The pattern holds — the wins are small tools plus the pipeline, not another platform.

How a new capability gets added¶

A checklist, so this stays a system and not a pile:

Name the job class and the department that owns it.
Write down what a good output looks like, and three real examples from this shop.
Give it the narrowest tools that can produce that output, on that department's token.
Build the review renderer — how a person sees current versus proposed, per item.
Run it on the sandbox against the three examples. Wrong twice means it is not ready.
Cost it. If a run costs more than the person's time it saves, stop.
Add it to the department's SKILL, add its refusals to the red-team suite, and name it in the department's SOP.

Step 5 is the one that gets skipped and the one that matters.

Open questions¶

Which model per job class. The cheap model is right for extraction and wrong for review; that is a per-class decision with a per-class cost, not a global setting.
Where unstructured input arrives. Most of these jobs need an inbox — quotes, acknowledgements, RFQs, receipts all arrive as email or a photo of paper. There is no intake path today, and it is likely the real prerequisite for half the list above.
Whether Yara's WhatsApp habit is an intake path or a distraction. It is where the photographs of receipts will actually come from.
What the accounting choice is, which is still blocking Finance entirely.

Log¶

2026-09-13: written. Tooling research folded in: most of its platform recommendations rejected as duplicating InvenTree; the wins are KiCad-ecosystem tools and the pipeline.