No production writes for agents
The first rule for operational agents is simple: no arbitrary write access to production data.
The rule is not anti-agent. It is the discipline applied to any fast writer. People make mistakes. Pipelines make mistakes. Agents make them too, at machine speed.
The wrong answer is a production database behind a long prompt that says "be careful" and a thin API that hopes every unsafe action was anticipated. That makes governance depend on how a model reads its instructions at the moment of action, and it turns every write into a high-stakes event. If it lands in production, cleanup is now production operations.
A knowledge graph needs a stronger pattern. Agents may do useful work, including proposing changes. The work happens inside a bounded context, on an isolated branch, through named and tested stories, with validation feedback on every commit, and promotion only through review and merge. That is how an agent works on Legra.
Safety is a workflow property
Better models help, but safety does not rest on model behavior. It is a property of the surrounding workflow, and for graph writes that workflow has four boundaries:
- Context: which workspace, use case and persona the session acts in.
- Action: which stories are visible and callable.
- Write: which branch receives proposed changes.
- Promotion: which validation, tests, review and merge gates move work into a long-lived branch.
Context Is King covers the first. This article follows the write path once that binding exists. The agent does not receive "the graph" as an open surface. It receives the stories valid in its context and a branch where its changes can be tested before they matter to anyone else.
Stories are the action boundary
A story is a named, typed, governed unit of work. It belongs to one persona and has typed inputs and outputs.
For an agent, the story is the tool. It does not run arbitrary updates, edit RDF by hand or invent write operations. It invokes stories such as "assess supplier disruption impact", "propose an alternative supplier", "request compliance review" or "draft a legal-entity correction."
That gives governance a handle. A story outside the session's use case and persona is not callable. Parameters that do not match the declared shape fail before execution. A story that writes lands on the branch assigned to the session. The safety is structural, not a convention hidden in a prompt.
Staging branches are the write boundary
A branch gives work a place to happen without touching the shared long-lived branch. A proposed change can be inspected, tested, abandoned or merged. Production does not move until promotion.
Staging branches matter for agents because agent work is multi-step. A useful agent inspects the graph, creates intermediate resources, links evidence, revises a classification, calls another story and only then produces a final proposal. Some intermediate states are incomplete. That does not make them useless. It makes them unfit for production.
If the work is wrong, the branch is dropped: a far simpler failure than production cleanup.
Validate while building
Strict validation everywhere sounds safe and breaks real work.
Many changes are invalid while they are being built. A bulk load creates entities before relationships. An agent needs several story calls before the graph is complete.
Rejecting every incomplete commit blocks progress. Accepting them silently hides whether the work converges.
Staging validation separates the two. Rules declare what is checked. The branch sets the enforcement. A long-lived branch is strict: violations reject the commit. A staging branch is lenient: violations return as warnings and the commit lands.
That gives people and agents the same feedback loop. After each commit the author sees what still fails. An agent keeps invoking permitted stories until the warnings clear. The rules that would reject a production write become guidance on staging. This is the pattern from From Graphs to Data Logistics: validate while building, promote when ready.
Stories need red and green
Validation checks the graph against shapes and rules. Conformance checks whether the story does what the business expects. Both are needed.
A story can have the right shape and still do the wrong thing: return the wrong rows, miss a required edge, or produce a state that conforms and fails the business.
Conformance scenarios are given-when-then cases attached to stories as graph resources: the starting state, the parameters, the expected rows or resulting graph.
For agents this turns stories into testable tools. A story is not fit for use because it exists. It is fit when its scenarios are green. The story is the permitted action; conformance is the evidence that the action behaves in the cases the business declared. The agent may still propose a bad change. The system makes that proposal visible, testable and rejectable before promotion.
Merge is the promotion gate
An agent writing to staging has not changed the long-lived graph. It has produced a proposal. Promotion is the merge into a destination, usually a strict long-lived branch. The separation is clean:
- the agent works quickly on staging;
- validation warnings guide the build-up;
- conformance scenarios test declared behavior;
- a reviewer inspects the diff and the provenance;
- the destination enforces strict validation at merge.
The merge gate is where shared state changes, and it should be boring by the time it happens. If staging has been driven to zero warnings and the tests are green, the merge promotes a state that was visible and checked all along. On Legra, a merge needs the rules to pass and every named party to agree.
A supplier scenario
A procurement-risk agent is bound to a workspace, the supplier-disruption use case and a procurement-risk persona. Its session exposes four stories: assess disruption impact, identify affected products, propose alternative suppliers, request compliance review.
The agent branches from production and runs the assessment. One delayed component affects two regulated products and one priority order.
It runs the substitution story. The first proposal is incomplete: a candidate supplier lacks certification evidence. The commit lands on staging with a warning. The agent runs the story that collects evidence. The next commit clears the warning and trips a conformance failure: a regulated product needs compliance review before a substitution is ready.
The agent requests the review. Now the branch has no warnings and the scenarios are green. A reviewer sees which products, suppliers, evidence links and review requests were added, and promotes the branch.
At no point did the agent touch production.
Not about slowing agents down
Treat every action as dangerous and the only safe agents are read-only assistants. Allow free writes to production and governance fails. Stories on staging branches are the split that lets agents do more.
Safe agent writes are not about making agents harmless. They give powerful tools a path that absorbs mistakes, exposes proposals and promotes only the work that passes the declared checks.
Try it in Legra
Work through reviewing data changes before connecting an agent. The MCP guide explains client setup and tool approvals; selecting a workspace does not by itself restrict the agent to that workspace.