Which manual steps a language model can take on, and which we never let it.

What we build

Three things, all inside workflows this silo already touches:

• Assistants inside a workflow — LLM-assisted development applied to the steps this silo already automates, so a model drafts the reply, the extraction or the routing, and the source it read is shown alongside the draft, not hidden behind it.
• Human-in-the-loop approval designs — the assistant proposes, a named person disposes, and nothing writes back until that person says so.
• Build, buy, or hybrid evaluations — run before any platform commitment, so a client is not sold a subscription when a scoped flow would do.

company delivery history · founder-asserted · 22 Aug 2026

Human-in-the-loop, by design

An assistant proposes; a person disposes. That is the whole design, and it holds regardless of how good the draft is: nothing the assistant produces reaches a system of record until a named person has looked at it and said yes.

What the diagram above shows, in full: a source system sits inside a boundary marking what the assistant may read — nothing outside that boundary is available to it. The four numbered steps are the workflow itself:

1. The assistant reads the source system, and only the source system — nothing outside the boundary shown.
2. It drafts a proposed action from what it read: a reply, an extraction, a routing decision. Nothing is sent or written at this point.
3. The proposed action goes to a named person at an approval gate, with the source shown alongside it, so the reviewer can check the draft against what the assistant actually read.
4. Only after that person approves does the action write to the system of record. A rejection sends the proposed action back to the assistant for revision; it never reaches the system of record on its own.

The one step in this sequence that never happens without a person is the fourth — see "What we will not build" below.

company delivery history · founder-asserted · 22 Aug 2026

Build, buy, or hybrid

Before any platform commitment, we evaluate whether the right answer is a scoped flow built specifically for the workflow in front of us, an existing platform configured to do the same job, or some of each. A subscription is not the default answer; it is one option we cost against the others, the same way any automation in this silo gets costed before it gets built.

company delivery history · founder-asserted · 22 Aug 2026

What we will not build

the boundary · the decision stays with a person · Scoring and decisioning

Fully autonomous decisions are out of scope — the same limit the rest of this site holds to, not a weaker version of it for this silo. An assistant here drafts, extracts, routes and proposes; it does not execute, and it does not decide.

We will not wire an assistant to send data anywhere a client has not explicitly agreed to send it — a document handed to a script that calls out on its own, a request routed through a service nobody signed off on. What a workflow can read and where it can write is agreed before anything runs, not discovered afterward.

And we will not ship a flow nobody can audit. If a person cannot see what the assistant read, what it proposed, and why a request was declined, the flow is not finished — the logging is not optional.

How it is engineered

The same production discipline the rest of this silo holds to applies here without exception:

• Fail-closed gates — when a validation check on the assistant's output fails, or the input does not match what the flow expects, the flow stops and waits for a person instead of guessing.
• Logged actions — what the assistant read, what it proposed, and what a person decided, all kept.
• Telemetry — the same monitoring discipline the rest of this silo runs on production automation.
• A defined rollback — agreed before the flow goes live, not improvised after it breaks.

company delivery history · founder-asserted · 22 Aug 2026

This is one part of Automation & Integration.