---
title: "Legal agents inside the organisation"
description: "An operating framework for legal agents: preserve what the organisation learns, prepare decisions as conditions change and keep people responsible for action."
language: "en-CH"
source: "/agents/"
canonical: "https://jonashertner.com/agents/"
content_id: "https://jonashertner.com/agents/#webpage"
type: "framework"
status: "current"
author: "Jonas Hertner"
published: "2026-08-27"
modified: "2026-09-05"
version: "2026-09-05"
citation: "Jonas Hertner, “Legal agents inside the organisation” (version 2026-09-05), https://jonashertner.com/agents/."
---
# Legal agents inside the organisation
What legal work teaches the company should remain available to it.
A contract exception, product clearance or settled dispute should inform the next decision. Legal agents can help a company retain that knowledge, notice relevant change and prepare the work that follows. This framework sets out how to organise that capability around the company’s objectives, legal obligations and the people authorised to decide.
01 / Decision
## Define the decision first.
Every material decision needs an owner, reasons and a route into action.
A company keeps changing after legal advice is delivered. A product acquires a new use, a contract is amended or an assumption proves wrong. The advice may still sit in an inbox while the people implementing the decision never see the conditions attached to it. Legal work needs a way to reconnect those changes with the earlier decision.
For each proposed use of an agent, specify the decision it will support, the person responsible, the sources it may use and the actions it may take. The resulting account should explain what prompted the decision, which facts and law mattered, what alternatives were considered and why one was chosen. It should also identify who may act, any conditions on that authority and the changes that would require reconsideration.
### One operating loop
**From a change in circumstances to a decision that can be revisited.**
#### 01 / Signal
A relevant legal or business change.
#### 02 / Context
Current law, facts and commitments.
#### 03 / Challenge
Options, objections and uncertainty.
#### 04 / Decision
Who decides, what and why.
#### 05 / Action
Who acts, on what conditions.
#### 06 / Outcome
What happened in practice.
#### 07 / Memory
What to retain and when to reconsider.
**Note:** A search result or draft becomes useful here when it helps explain the decision and what followed.
02 / Memory
## Keep the reasons as well as the documents.
Every matter should begin with what the company already knows and leave the company knowing more.
A signed contract tells the company what it agreed. It may not explain why an exception was accepted, who approved it or which assumption made the risk tolerable. Keeping that reasoning, with appropriate access and retention rules, gives the next team something it can examine and learn from.
Link a decision to the facts, law, products, entities and commitments on which it depended. If one changes, the system can bring the affected decision back to the responsible person. That link must itself be checked: a relationship inferred by a model remains a hypothesis. Earlier advice also needs to be read on its own terms, including its date, scope and assumptions.
### What the organisation should retain
The company knows how a decision was implemented, which exceptions followed and what happened in practice. Its systems should preserve that knowledge and make it available only where a defined task requires it. Outside counsel can then work from a precise instruction and an intelligible history. Their advice should return with its author, date, scope and assumptions attached, so the company can use it again on an informed basis.
03 / Operation
## Keep relevant work moving between decisions.
Give each agent a defined job, permitted sources and a clear point at which to involve a person.
An agent can monitor specified sources for changes in law or receive events from the company’s business systems. Within its assigned scope, it can flag a possible issue, open a matter or update an existing one. The coverage must be explicit: which sources are checked, how often, which events count and what the system may miss.
Before a review, the agent can assemble current sources, retrieve earlier advice, identify missing facts and prepare questions for research. A consequential recommendation should face a separate examination of its evidence and assumptions, proportionate to the stakes. This may require fresh research or review by another person. Asking the producing model to check itself, or merely switching models, does not establish independent assurance.
After a person decides, the agent can pass the authorised instruction to the appropriate team, monitor specified conditions and retain evidence of completion. Novel issues, disputed facts, conflicting authorities or a breached limit should bring the matter back to a responsible person. The design must give that person enough time and information to intervene.
04 / Control
## Keep control when the technology changes.
The organisation should be able to replace a model or provider without losing its knowledge or controls.
The lasting investment is the system around the model: its sources, permissions, instructions, tests, review requirements and history of actions. Together, these determine what an agent can read, do and pass on. The organisation needs the ability to inspect, export and maintain them when it changes a component or supplier.
01 / Sources
### Keep each claim connected to its evidence
Legal propositions should lead back to the relevant authorities; statements about the business should lead back to the underlying documents or system entries. An entry can itself be mistaken. Preserve its date and origin, distinguish it from an inference and restrict access to those entitled to see it. Decision histories, source references and test results should remain accessible independently of the model that helped produce them.
02 / Runtime
### Know where the information goes
Models and the software operating them may run locally, on infrastructure the organisation controls or through an approved external service. Assess the whole arrangement: model processing, connected tools, storage, logs, support access, backups, keys and network routes. A locally hosted model may still send information through an external component. For every such transfer, establish what leaves, why, who may access it and how long it is kept.
03 / Authority
### Grant authority explicitly
Specify what an agent may read, produce, communicate and change. Assign an owner, scope and expiry to each permission, and define how work is reviewed, stopped or escalated. Better test results may justify proposing more responsibility for a system; they do not grant it. People retain professional responsibility and the authority to commit the organisation. Those responsibilities apply wherever the software runs.
### Build in order
Begin with one decision and its sources. Define the permissions, expected results, failure conditions and human review, then test the proposed process. Add scheduled operation only when those foundations work. Introduce further agents and handoffs as the need arises, with clear ownership at each step. Every live process needs these controls from the outset.
05 / Board
## Ask for evidence that the work improves.
The board should be able to see what this capability contributes, where it can fail and who is responsible. Six questions make that examination concrete:
1. Which company objectives and decisions should this improve, and how will we know?
2. Which legal or business changes will the system detect, and what will it miss?
3. Can we follow a material recommendation to its sources and identify what would require reconsideration?
4. Which decisions require human review, independent challenge or formal approval?
5. Where is information processed, who can access it and what can the system do outside the organisation?
6. Can management show how serious errors are detected, how actions are checked and how work continues if a provider changes?
Conclusion
## A continuous legal function.
The company should be able to notice a relevant change, understand which earlier decisions it affects, prepare the question for the right person and carry an authorised answer into action. Each matter should leave behind reasons and experience that the next team can use. That is the continuing legal capability worth building.
Jonas Hertner
Document
Legal agents inside the organisation Published 27 August 2026 Revised 5 September 2026 [jonashertner.com/agents/](/agents/)
Related
- Supporting note: [Legal work that stays useful](/pivot/)
- [AI in legal work](/notes/ai-in-legal-work/)
- [Main page](/)
Formats
- [Markdown edition](/agents/index.md)
- [LLM index](/llms.txt)
- [Site privacy](/#privacy)
## Scope
This is an operating framework, not legal advice or a statement that any particular use is lawful. The applicable law, professional duties, corporate authority and technical controls must be assessed for the organisation and the work concerned.
## Privacy
No visitor analytics or advertising code runs on this page. It sets no cookies. GitHub Pages processes technical request data, including IP addresses, to deliver and protect the site.
© 2026 Jonas Hertner · Independent lawyer