AI Automation
Agentive AI in Australian legal practice: what's possible, what's gated, and what isn't yet
Note on what this article is. This piece describes the current state of agentive-AI tooling and the operational considerations Australian law firms encounter when evaluating it. It is not legal advice, and it does not constitute professional advice on a solicitor’s obligations. Any deployment decisions should be assessed by the firm with reference to current regulator guidance and, where relevant, independent professional advice. References to regulatory rules are provided for context only; their interpretation and application to a specific deployment is for the firm and its advisers.
Quick read. Agentive AI — AI systems that can take multi-step actions, not just answer questions — is technically buildable today for Australian law firms. The two open-source frameworks Australian solicitors most often reference are OpenClaw and Hermes Agent, both released in 2026; they sit on top of model choices that include the Hermes family from Nous Research, Anthropic Claude, OpenAI models, and various local-inference options. The harder questions are not technical. They are: (1) what the relevant legal-tech platform (typically LEAP) exposes via API; (2) what content libraries (typically By Lawyers) make available beyond their native UI surface; and (3) how a firm satisfies its confidentiality and supervision obligations under the Australian Solicitors’ Conduct Rules. This article walks through each layer plainly.
What “agentive AI” means in practice
A useful distinction:
- Generative AI produces text, code, summaries, or drafts when asked. The human reads the output and decides what to do.
- Assistant-shaped AI sits inside an existing application (a PMS, a word processor, a CRM) and helps with specific tasks — summarising, drafting, comparing. The human stays in the driver’s seat; the AI offers options.
- Agentive AI can take a sequence of actions across systems to advance a workflow — create a record in a PMS, send a message, schedule a follow-up, update a status — with or without a human approval step between each action.
The first two are well-trodden in Australian legal tech as of 2026. The third — agentive AI — is the frontier. Most LEAP firms have used LEAP’s own assistant-shaped AI (LawY, Matter AI, Generator) or third-party tools like Spellbook. Few have deployed truly autonomous agents into matter handling, and that is for substantive reasons that this article walks through.
The framework layer
When solicitors investigating agentive AI describe the architecture, two open-source frameworks have come up consistently in 2026:
OpenClaw
OpenClaw is an open-source AI agent framework with a skills-based extension model. Per its documentation, it runs locally on the user’s machine, supports Anthropic Claude (primary), OpenAI, and various local models, and is currently in Beta. The OpenClaw project is positioned as a personal AI assistant — its broad consumer-style integration set (chat platforms, email, calendar, browser automation) reflects that focus.
In our experience, OpenClaw fits well where the workflow is personal-productivity-shaped and the user wants polished consumer-style integration. For deployment into Australian legal practice, OpenClaw’s skill system can be extended with custom skills for legal-specific systems, but the framework itself is not positioned as a compliance-certified platform — firms considering it should assess the deployment against their specific regulatory framework.
Hermes Agent
Hermes Agent is an MIT-licensed open-source autonomous agent framework released by Nous Research in February 2026. Per its documentation, it supports models via Nous Portal, OpenRouter (200+ models), custom OpenAI-compatible endpoints, and local vLLM. It provides persistent memory, parallel sub-agents, scheduled automations, and a skill system via SKILL.md files. Documentation specifically emphasises local data storage and container hardening as design defaults.
In our experience, those architectural defaults make Hermes Agent a more directly applicable starting point for deployments where local-data handling is load-bearing — which is often the case in legal practice. That doesn’t make Hermes Agent “compliant” with any specific regulatory framework on its own; deployment decisions still depend on the workflow, the model choice, and the firm’s professional advice. But the architecture starts from defaults that align more naturally with confidentiality-sensitive workloads.
Distinguishing the model from the framework
A point of frequent confusion: “Hermes” refers to two related but distinct things in this space. Hermes Agent is the framework discussed above. The Hermes family of models (Hermes 3 and Hermes 4, also from Nous Research) is a set of open-source language models fine-tuned for function calling and agentic workflows. Hermes Agent can run on a Hermes model, on Claude, on OpenAI, or on a local-vLLM model per the project documentation. The choice of model is separate from the choice of framework, and it materially affects cost, latency, and where matter data flows.
The platform layer: what LEAP exposes
Most Australian law firms run on LEAP. Any agentive AI that wants to take action against matter records, billing, or trust accounting needs to do so through LEAP’s integration surface.
LEAP runs a public developer presence at leapdev.io with documented REST APIs and a marketplace for third-party integrations. The specifics of API scope (read-only, read-write, what endpoints are exposed at what partner-tier) are documented inside the developer console, and access is granted on application. Firms considering agentive AI builds against LEAP should engage with the developer console early in the planning process; the available API surface shapes what is and isn’t buildable.
LEAP also publishes its own AI features — LawY for legal Q&A with human-in-the-loop verification, Matter AI for matter-scoped extraction and summarisation, and Generator for template drafting. These are assistant-shaped rather than agent-shaped: they help the solicitor with specific tasks, they do not autonomously take action across the matter file. Agentive AI built on top of LEAP is a different shape of project and one LEAP’s own AI roadmap has not (publicly, as of mid-2026) addressed.
The content layer: By Lawyers and the licensing reality
A common starting picture for “agentive AI in LEAP” is that the agent reads By Lawyers precedents to build matter plans automatically. As far as we have been able to find as of mid-2026:
- By Lawyers content is distributed as a subscription add-on inside LEAP and surfaced within the LEAP UI — auto-populating forms, presenting precedents within the matter file.
- We have not been able to identify a publicly-documented developer API for By Lawyers content.
- We have not been able to identify a publicly-documented third-party content licensing programme.
What that means in practice is that a build which expects to programmatically read By Lawyers content from outside LEAP involves licensing considerations that the firm would need to assess on its own facts.
There are two patterns that sidestep this licensing question, and they sit at different ends of the architecture:
Pattern A — the firm’s own template library. Build the matter-plan library the agent uses from the firm’s own templates and process knowledge, scoped to the matter types the firm actually handles. This keeps the matter-plan IP with the firm and produces outputs that the firm can stand behind because the firm controls the source content. By Lawyers continues to serve its native role inside LEAP for direct use by the solicitor.
Pattern B — an app that operates inside each user firm’s authenticated LEAP session. This is the pattern most LEAP marketplace apps look like today. The app is built as a SaaS product; each end-user firm authenticates its own LEAP API access; the app operates within that firm’s authenticated environment. Any By Lawyers content reaching the app does so as the firm itself, through the firm’s existing By Lawyers subscription, not via independent licensing by the app maker.
Pattern B shifts the licensing question from the app maker to the end-user firm — which already has its By Lawyers subscription. It is also the pattern where the open technical question becomes what content the LEAP API actually exposes to third-party apps acting on behalf of authorised users. Some platform content surfaces only inside the LEAP UI and may not be available via the public API; other elements may be. The feasibility of this pattern for any specific agent workflow depends on confirming the API surface in LEAP’s developer documentation. Developers building in this pattern would typically also need to satisfy LEAP’s marketplace terms for third-party apps interacting with platform content.
Pattern A and Pattern B are not mutually exclusive. A common shape is to use Pattern B for everything that flows through the LEAP API as a user, and Pattern A — the firm’s own templates — for matter-plan content that isn’t available through the user-mediated API surface.
The regulatory layer
Several state regulators and the Law Council of Australia have published guidance on the use of AI in legal practice. As of mid-2026, the substantive Australian guidance addressing AI use includes:
- The joint statement from Law Society of NSW, the Legal Practice Board of Western Australia, and Victorian Legal Services Board + Commissioner on AI use in Australian legal practice.
- Queensland Law Society Guidance Statement No. 37 — AI in Legal Practice.
- The Law Council of Australia’s AI page, which coordinates national-level position-development.
Solicitors remain bound by the Australian Solicitors’ Conduct Rules (Legal Profession Uniform Law jurisdictions) or state equivalents. Two rules are particularly relevant in conversations about agentive AI, though we note again that interpretation of these rules and their application to specific deployments is a matter for the firm and its advisers:
- ASCR Rule 9.1 (confidentiality) constrains what information can be disclosed outside the firm.
- ASCR Rule 4 (competence and supervision) frames the solicitor’s responsibility for work performed under their supervision.
The published Australian regulator guidance to date addresses generative and assistant-shaped AI primarily. The specific question of autonomous, multi-step AI agents acting inside legal practice systems has not yet been the subject of targeted regulator guidance as of mid-2026, to the best of our knowledge. The most defensible posture in the meantime, in our experience, is to design for confidentiality and supervision by construction rather than as a policy bolt-on — meaning the architecture itself makes it difficult or impossible for the agent to act in ways that conflict with those obligations.
What “by construction” looks like in practice
A handful of design principles that, in our experience, support deployment of agentive AI in Australian legal practice while keeping the architecture defensible:
-
Model selection that keeps matter content on infrastructure under the firm’s control or under specific contractual terms. Local-inference models (Hermes 4 via local vLLM, or comparable) run on hardware the firm operates. Where remote-API models are preferred for capability reasons, the model provider’s enterprise terms should explicitly exclude training on the firm’s data and provide appropriate confidentiality undertakings.
-
Action surfaces that gate every state-changing action through a human approval step. The agent proposes; the solicitor approves; the system then commits. Logs capture both the proposal and the approval. This pattern makes the workflow auditable in a form that maps to the supervision principle.
-
Audit trails that record every agent action, every input, every model output, and every human approval, retained for the period the firm’s document-retention policy specifies. Without this, the workflow is not auditable.
-
A narrowly-scoped first build. One workflow, deeply done, with clear boundaries. “Intake to suggested matter plan” is a common first project shape. “Full agentive practice management” is a much larger project and not usually a starting point.
-
Documented policy on what the agent can and cannot do, reviewed by the firm and updated as the deployment evolves. This is not the technical layer; this is the firm’s policy framework, which is its own responsibility.
A common-shaped first project
In our experience, the version of agentive AI that fits comfortably inside an Australian law firm’s current operations is a matter-plan co-pilot: a tool that takes a new client enquiry, proposes a matter plan based on the firm’s own templates, presents it to the solicitor for review and adjustment, and on approval creates the matter in LEAP with the agreed plan populated.
Typical shape:
- Agent framework: Hermes Agent (or OpenClaw, depending on the firm’s preferences) with a custom skill for LEAP API operations.
- Model: Hermes 4 via local inference (typical default for confidentiality), or Claude on no-training enterprise terms if the firm needs the additional capability and is willing to contract for it.
- Knowledge base: the firm’s own matter-plan templates, structured for agent consumption.
- Human-in-the-loop: every matter created via the agent flows through the solicitor before commit to LEAP.
- Audit: every agent input, model output, and human approval logged.
This is meaningfully buildable inside the kind of budget and timeline a small Australian firm can sustain. It is also a foundation that extends naturally over time — more matter types, more workflow steps — without ever needing to remove the supervision gate.
What isn’t buildable yet (or at all)
A few patterns that come up in conversation but that we typically recommend against, for practical or licensing reasons:
- An app that directly licenses By Lawyers content from outside the user firm’s own subscription. This sits at the boundary of how By Lawyers content is distributed. The user-mediated pattern described above (Pattern B) addresses the same need differently and is the path most LEAP marketplace apps currently take.
- An agent that operates fully autonomously inside LEAP with no human review of state-changing actions. Technically possible; in our experience, not a defensible posture under the supervision principle as currently articulated.
- An agent that gives legal advice to clients directly. Whatever the technology can do, the framing matters — agentive AI in legal practice is a productivity tool for the solicitor, not a substitute for legal advice given by the solicitor.
- An agent that handles trust account transactions. Trust accounting has its own regulator framework and is not somewhere we recommend agentive AI for early deployments.
The honest conclusion
The technical components for agentive AI in Australian legal practice exist and are reasonably mature. The framework choice (OpenClaw vs Hermes Agent vs other), the model choice (local vs remote, Hermes vs Claude vs OpenAI), and the integration path (LEAP API, custom matter-plan library) are all decisions firms can make today. What firms cannot do is assume away the regulatory layer or the By Lawyers licensing wall. Both are real and both shape what gets built.
The firms we’ve seen approach this most successfully start narrow, design for confidentiality and supervision by construction, take their professional obligations seriously throughout, and treat the technology as a productivity layer for the solicitor — not a replacement for solicitor judgement. There’s real value to be captured that way. The full-agentive picture — an AI that runs the legal practice autonomously — is a different conversation, and one that the technical layer doesn’t bring meaningfully closer.
This article is general information about technology integration in Australian legal practice. It is not legal advice and does not address any specific firm’s circumstances. Solicitors considering deployment of agentive AI in their practice should seek qualified professional advice on their obligations under the Legal Profession Uniform Law (or equivalent state regulatory framework) and the Australian Solicitors’ Conduct Rules. References in this article to current regulator guidance, vendor capabilities, and platform integration surfaces reflect publicly-available information as of mid-2026 and may change.
More reading
Nookal integrations for multi-practitioner Australian clinics
Where Nookal earns its place over Cliniko and Halaxy for multi-practitioner clinics — and the integration patterns that turn a strong PMS into a complete operational platform.
IntegrationsHalaxy API: what you can and can't build with it
A practitioner's view of the Halaxy API surface — what it covers, where it stops, and the integration patterns Australian allied-health practices use to bridge the gaps before considering a platform move.
IntegrationsConvertKit integrations: the five patterns we build when Zapier isn't enough
Five custom integration patterns we keep building for ConvertKit — Bonjoro, Slack, Facebook Custom Audiences, Airtable, Kajabi — and the decision points where no-code platforms run out of road.