Legal AI, not a coding agent with scaffolding. | Lexifina<br>FeaturesSecurityPricingBlogChangelogSign in

Blog/Research/Real legal AI

Blog/Research/Real legal AI

Legal AI, not a coding agent with scaffolding.<br>Alan Yahya·July 15, 2026·12 min read

The majority of legal AI use is transacted through agents built for coding. Let’s focus on what a system built for a legal purpose might tangibly achieve.<br>Generally, legal AI should find the strongest supportable arguments, identify the correct evidence, and make that evidence easy to verify.<br>An agent workspace is the correct interface. The user sees an audit trail including the tools and sources used by the model. They are able to control the context by creating side chats, and define specific sources and skills to manipulate model behaviour.<br>Agent grounding must happen at the level of individual claims and edits. It is simply not good enough to retrieve an external document and cite it as a whole. This level of granularity depends on the argument- which may call for an individual sentence, a paragraph, or a set of pages. The hierarchy, status, and intended purpose of each source should be explicit. That information can be stored via an ontology or similar graph network. For example, legal authority vs client facts, current document language vs previous drafting language.<br>When the AI suggests an edit, the lawyer should be able to see why it made that change. That includes the original instruction, the clauses it reviewed, the facts it considered, the legal sources it relied on, and any warnings or uncertainties that can be calculated deterministically and packaged neatly for the user.<br>AI should not make changes automatically. It should show the proposed edit as a redline (or tracked change!) that can be processed individually. This workflow goes some way to deterrings users from blindly accepting changes. Needless to say, changes are logged and revocable at any time using an underlying version control system. Letting a probabilistic process edit a document without a version control system would simply be reckless.<br>Skills, memory and compaction should preserve access to evidence. They should not replace evidence with summaries. That is not good enough in a legal use-case. Rather, it should leave behind a lookup artifact that allows the exact original content to be viewed for factual information.<br>AI, even evidence grounded, must never subvert legal judgment. Sources may be outdated, narrow, incomplete, or limited to a particular jurisdiction. The system should make these limitations more visible, not less, and enable a lawyer to make fully informed decisions with up-to-date information.<br>Coding agents only enforce mechanical correctness, with interpretation as a guideline. Lawyers are being sanctioned because evidence grounding is being treated as an optional guidance layer, rather than a core product or workflow requirement. And unfortunately, that is the current story for legal AI tools.<br>Deleting a clause: did the patch match, and were its dependencies checked?<br>Take the instruction: delete Section 12.7 because its obligation appears to be duplicated elsewhere. There are two different ways this can go wrong. The text may have changed since the edit was prepared, or another clause may still refer to Section 12.7.<br>Codex's native patch path addresses the first failure directly. It looks for the old lines in the current file:<br>codex/codex-rs/apply-patch/src/lib.rs:765<br>Code example+−CodePseudocode<br>let mut pattern: &[String] = &chunk.old_lines;

let mut found =<br>seek_sequence::seek_sequence(original_lines, pattern, line_index, chunk.is_end_of_file);<br>If the expected text is no longer present, the patch fails rather than applying against a stale location:<br>codex/codex-rs/apply-patch/src/lib.rs:787<br>Code example+−CodePseudocode<br>if let Some(start_idx) = found {<br>replacements.push((start_idx, pattern.len(), new_slice.to_vec()));<br>line_index = start_idx + pattern.len();<br>} else {<br>return Err(ApplyPatchError::ComputeReplacements(format!(<br>"Failed to find expected lines in {}:\n{}",<br>path,<br>chunk.old_lines.join("\n"),<br>)));<br>That is a strong textual invariant, but it says nothing about legal-document dependencies. Codex can search for cross-references, but the native patch application does not require that search to have happened.<br>Lexifina records whether a structured cross-reference lookup for the section completed successfully:<br>Code example+−CodePseudocode<br>def _completed_cross_reference_terms(ctx: ToolUseContext) -> set[str]:<br>terms: set[str] = set()<br>for row in getattr(ctx.document_state, "tool_call_log", None) or []:<br>if str(row.get("tool_name") or "") != "get_cross_references":<br>continue<br>if str(row.get("status") or "").lower() != "ok" or row.get("is_error"):<br>continue<br>raw_input = row.get("raw_input")<br>if not isinstance(raw_input, dict):<br>raw_input = row.get("input_preview")<br>if not isinstance(raw_input, dict):<br>continue<br>term = _normalized_reference_term(raw_input.get("term"))<br>if...