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 Dinis Cruz, 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.
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.
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.
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 eight articles
Who answers
Responsibility stays with the grant, and a written policy draws the line between deployer and vendor.
- Who owns the words: agents can make decisions, but they cannot hold responsibility. Agents in loops make real decisions, but responsibility stays with whoever granted the reach; disclosure is a label, not a team to manage.
- The policy draws the liability line: an answer to Ralf Thomas on agent accountability, and why every agent in a loop should take a behaviour policy beside its prompt. An answer to Ralf Thomas: the shell game works because nothing is written down, and a behaviour policy's explicit prohibitions move the liability line.
- A policy beside the prompt: a proposal that every agent takes a behaviour policy as an input, with enforcement and liability attached, and why aviation and payments say the vendors should want it. A proposal: every agent takes a behaviour policy beside its prompt, which the vendor accepts and answers for, as aviation and payments learned to.
Where the person belongs
The cost of undoing decides it, and a service built on that rule.
- The human in the loop, safety net or bottleneck: both, until you decide which outputs need a person and give that person the why. Checking every output is a bottleneck and a weak safety net; put the person where it cannot be undone, and let controls do the rest.
- The human in the loop is a spectrum: how cheap it is to undo decides where a person belongs, and why the newsroom ships on its own while my email still waits for me. How much to let an agent ship on its own depends on how cheap it is to undo and how mature the controls are, and both of those move.
- Stop the bleeding, then ask for it back: a helper, an agent and a friendly letter for the subscriptions you keep and do not use. A helper and an agent ask what you used, ask nicely for a pause and a refund, stop the payments either way, and publish what each company did.
Records, and the agent that reads them
Where the records run out, and writing for the reader's agent as well as the reader.
- The records ran out: a fresh agent found the shared contract in two MCP calls, and where sgit and RiskMandate fit at the edges. A fresh agent found a shared contract in two MCP calls from build records; where the records stopped is exactly where evidence labels and sgit vaults fit.
- Brief the agent too: the people I talk to work with agents, so what I send has to reach both. The people I advise read through agents. Content needs a second package, a brief for their agent, and memory, so it reads what changed, not everything.
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.