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
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.
A relevant legal or business change.
Current law, facts and commitments.
Options, objections and uncertainty.
Who decides, what and why.
Who acts, on what conditions.
What happened in practice.
What to retain and when to reconsider.
A search result or draft becomes useful here when it helps explain the decision and what followed.
02 / Memory
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.
03 / Operation
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
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
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
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
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.
05 / Board
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:
Conclusion
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.