Build1 publisher3 min readPublished
An enterprise AI reference diagram gates only its write and send connectors
Part 4 of a dev.to enterprise AI series puts a person in front of the write and send connectors and leaves read paths alone, with the refusal enforced by the tool layer instead of a sentence in the prompt.
The Engineer · Build desk
What happened
- Part 4 of a dev.to series on enterprise AI adoption covers two connector classes, write and send, plus a dashed human approval box labeled 'send & write need a person'.
- The approval arrows on the diagram run to the write and send connectors only, leaving read connectors outside the gate because reading was the work of stage 3.
- Stage 4 is where a bad run stops being contained, because a record gets changed or a message goes out and cannot be pulled back.
- Done, by the post's definition, has send connectors enumerating their channels and recipients, every send carrying the approval that released it, and each approval naming one send rather than a class.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Splitting read and write into two connectors means two scope reviews and two sets of credentials per system, and the whole-repo read scope that was fine to grant cannot be reused on the write path.
- decision Any team that encoded do-not-merge in a system prompt now has to decide whether to move that refusal into the tool, since a prompt rule holds only as long as the model keeps honouring it.
- cost Per-send approval puts a person on the critical path for every outward message, and at Qingchuan's scale the bill is paid in interruptions to the 10 people in the two functions that own those channels.
- contradiction The post's own account makes writes recoverable and sends not, yet one dashed gate covers both, so a team copying the diagram pays the same approval cost for a revertable commit as for an email it cannot recall.
The two gated boxes do not carry the same risk, and the post says why. A write connector changes something inside systems the company controls, and there is a previous state to go back to; a bad commit has a diff, and recovering from it costs internal time that no customer sees [6]. A send leaves no diff, and whether the content was any good is a separate question from whether it should have gone out at all; the second one is not answerable after the fact [10]. Both still sit behind the same dashed box, drawn in a different color between the agent runtime and the two connectors [23].
Read and write are drawn as two connectors, not one connector with a flag. The reason given is scope: a connector scoped for reading the whole repo is a reasonable thing to have, and the same scope for writing is not [7]. That separation only helps if the write side is recoverable and attributable. The post's definition of done requires every write to leave a diff or a prior version a person can restore without asking the agent. The write also has to be attributable to an account issued for that workflow, not to whoever first lent their own [8].
On the send side, the author wrote that "an approval covers the action it was given for and does not extend to a neighboring one" [12]. In a recent publishing run two posts had been approved, and the composer for one of them came up behind a dialog asking to accept updated terms of service. Accepting terms is a different action from posting, so nothing got clicked. The run stopped there and waited for a person [13]. The rule behind it is that each outward publish needs a person to say yes at that moment, "not a batch authorization granted in advance" [11].
The location of the refusal is the part I would copy first. The common build is to write the rule into the prompt, as in do not publish, do not merge, do not touch the customer records [15]. A prompt is a request, and the model can misread it, drop it later in a long run, or talk itself past it while trying to be helpful. A denied action is not a request, and it has no second reading [16]. In the author's setup the tool refuses a pull request merge and a remote branch delete. The prompt is not what stops them [17]. He wrote: "I tested that rather than assuming it" [18]. The session prepares the pull request and he presses merge himself [19].
Qingchuan, the company in the walkthrough, is made up and only serves to walk the stage [4]. So it reports no numbers on approval latency, sends per day, or how often a person said no. Its write and send examples come out of two functions, 8 engineers and 2 in marketing, which is 10 of about 40 staff [22]. For the gate placement to transfer, the stage-3 preconditions have to hold first: reads go through read-only connectors inside a sandbox, and the log of what the agent read is one the agent cannot rewrite [20].
What to watch
- Whether the series ever publishes measured approval load, such as sends per day and how often a person refused one, instead of a walkthrough of an invented company.
- Whether tool-layer refusals hold when the agent can reach the same action by another route, for example a git command line inside the sandbox after the tool refuses.
- Whether contract dialogs of the terms-of-service kind get their own denied-action entry, or keep stopping a run and waiting for a person.