for agents/llms.txtv0.12.119

Home / SGit Newsroom / Newsletter / Issue 7

SGit Newsroom · Issue 7 · 2026-10-18

Who answers for an agent: decisions without responsibility, a policy beside every prompt, and where a person belongs in the loop

By , written with the Journalist

Abstract: Agents in a loop make real decisions now, so who answers when one of them goes wrong? Eight articles from 11 to 13 October give one answer from several sides. Responsibility does not travel with the decision; it stays with whoever granted the reach. The shell game of blaming the agent, the customer or the contract works because nothing was written down, and a behaviour policy written down moves the line between the deployer and the vendor; given beside the prompt as a third input, with the vendor answering for the rows it accepted, it could do for agents what moving liability did for payments. A person checking every output is a bottleneck and a weak safety net; the person belongs where an output is expensive to undo, which is why this newsroom ships on its own while every email waits. And at the edges: records that run out where behaviour starts, briefs written for the reader's agent as well as the reader, and a subscriptions service where the freelancer types the secrets and sends the drafts, and the agent does the rest.

When an agent decides, who answers for it? Issue 4 argued that an agent's limits have to sit outside the agent. This issue asks the next question: once agents make real decisions, where does the responsibility sit, what written thing draws the line when they fail, and where should a person stand in the loop? Eight articles from 11 to 13 October, the week this newsroom started shipping on its own. It follows issue 6, the reader's own newsroom.

Who answers for an agent, in six pictures, one from each of six of the articles

Decisions without responsibility

Who owns the words starts from a question an early user of the agentic workflow behind agent@riskmandate.ai asked: if the agents gather and draft, and I review, sign and send, does presenting them as a team imply an agency they do not have? The answer has two halves. Models running in loops and calling tools make real decisions; every tool call is a choice. But the responsibility does not move with them:

Responsibility does not travel with the decision. It stays with whoever granted the reach and set the mandate.

Talking to the agents is normal; going around the accountable person is not, and the only party who would try is an attacker with an injected instruction. The best analogy is an employee with a job description, and an Agent Behaviour Policy is that job description, published.

A policy that draws the line

The policy draws the liability line answers Ralf Thomas, who asked on LinkedIn why agents should be treated differently from an employee who wrecks a client's systems. His four moves of the accountability shell game, blame the agent, blame the customer, hide behind the contract, disclose late, are a good map, with a few of the cases stated more carefully. They work because nothing was written down between the click on allow and the failure. Once a prohibition is written and given to the agent, a dispute changes shape:

It is about whether the product did what it was explicitly told.

Two directions of liability: towards the world the deployer answers; between the deployer and the vendor, the written policy decides whose failure it was.

A policy beside the prompt turns that into a proposal. Beside the vendor's system prompt and ours, an agent should take a third input, a behaviour policy written to a published standard, which the vendor accepts, enforces where it can, reports against and eventually answers for. Two industries show why the vendors should want it. At 1995's rate of fatal airliner accidents, 2025's 38.7 million flights would have meant about 105; there were 12, because every crash was news. And payments got some of the best security teams anywhere for a simpler reason:

The moment you pass the liability for fraud to the company, its security picks up.

Where the person belongs

The human in the loop answers a roundtable's question, safety net or bottleneck, with both, and mostly neither: people approve almost everything they are shown, 93% of permission prompts in one vendor's measurement. The useful question is which outputs need a person. Put the person where an output cannot be undone and the blast radius is large, and replace the other checks with controls that do not get tired. On the day it was written this newsroom shipped fourteen releases with no person approving each one, while every email still waited:

An article can be corrected tomorrow. An email cannot.

The human in the loop is a spectrum takes that contrast further. The test is how cheap it is to undo, Amazon's one-way and two-way doors, set against how mature the controls and the record are. Email is a one-way door and still an explorer; an article here is a two-way door with a validator, tests and a leak scan behind it. Both positions move, as readership grows and as the email controls mature:

The line is a decision to revisit, not a setting.

The spectrum: how much it costs to undo, against how mature the controls and the record are. The newsroom's articles ship on their own; email in my name waits for me.

Where the records run out, and who reads them

The records ran out answers Ignacio Aldama of Bit Cloud, whose fresh Claude Code session found a shared contract in two MCP calls and left it alone, and who then said honestly where the records stopped: structure, not behaviour; a green build over tests that did not run; a demo's public signing secret; memory not tied to a version. Each edge has a name in RiskMandate's vocabulary, and one line carries the rest:

A test that skips is a control that did not run.

Brief the agent too is about the other end of a message. A founder handed an article on threat tiers to their agent, which saw the team planning for states while backups were not done, and reset the target. So content needs a second package, a brief for the reader's agent, written as data, not as instructions over its person, with deltas so an agent that comes back reads only what changed:

The agent pays not to pay.

Two controls, and everything else automated

Stop the bleeding, then ask for it back puts all of this to work on a small business: a helper, paid from the savings, who stops the subscriptions a person keeps and does not use, asks politely for a pause and a refund, and records every answer in an open register. The agent drives the browser and writes the letters, under a behaviour policy written before the first run, and the person sits only where the doors are one-way:

Secrets are entered by the freelancer. Drafts are sent by the freelancer. Everything else is automated.

The helper's agent as a behaviour policy: what a signed-in session can reach, what is in the mandate, and which rows still owe a real control.

The eight articles

Who answers

Responsibility stays with the grant, and a written policy draws the line between deployer and vendor.

Where the person belongs

The cost of undoing decides it, and a service built on that rule.

Records, and the agent that reads them

Where the records run out, and writing for the reader's agent as well as the reader.

This is issue 7 of the SGit Newsroom newsletter, also published on LinkedIn in Deterministic GenAI. Every article it links to is on newsroom.sgit.ai, with its sources and its data. To get the next issue by email, subscribe at newsroom.sgit.ai/subscribe.

← All issues