As of October 2026, intake may be acquiring a second front door. Alongside the web form and the phone line, at least one firm has publicly described an interface built for software. This article asks one question: if a firm lets outside AI agents submit or query intake directly, what should be tested first, and why might the interface matter more than the agent?
Two caveats up front. Nothing below shows that any firm is losing leads or revenue. Leakage in agent-mediated intake is a hypothesis that needs first-party data. And the strongest technical evidence here comes from a general web-security preprint, not from legal intake, so every application to intake below is our inference, not a finding of the study.
What has been reported
In a July 2026 LawNext episode, host Bob Ambrogi interviewed Ryan Walker, a former Casetext CTO. Walker co-founded General Legal, which describes itself as an AI-native law firm. The LawNext write-up says the firm has some 400 clients and an MCP server that lets clients' AI agents engage the firm directly. LawNext describes this as possibly a first for a law firm. That is attributed reporting of a podcast conversation. It says nothing about how the interface is configured, what it permits, or how it performs.
On the software side, LawNext's report on Intapp's Celeste covers a vendor launch. Intapp positions Celeste as agentic AI for the business side of a firm, with playbooks for functions including intake and conflicts. According to Intapp, ethical walls, need-to-know restrictions and audit requirements apply to the AI as they do to people, and firms can produce a record of every action it takes. Those are vendor claims. The article also quotes BakerHostetler's CIO saying the firm believes Celeste can have a positive impact on its intake and conflicts process. That is an expectation, not a measured result.
Taken together, these pieces show one firm describing an interface for clients' agents and one vendor describing agents that operate intake. Our reading is that this is a direction worth preparing for, not an established trend. Neither source shows that either approach reduces missed matters.
What a security benchmark says about interfaces
A preprint titled The Agent in the Middle studies what happens when web services expose backend interfaces that agents call directly instead of navigating a website. It is an arXiv abstract, so treat its numbers as the authors' claims, not reproduced or peer-reviewed results.
The authors built VELA, an executable benchmark with 44 vulnerabilities across twelve web application families. They tested three commercial agents across several interface configurations. Per the abstract:
- In the reference configuration, the agent realized every attack that direct interface invocation realized, so exploitability was set mainly by the interface.
- 91% of vulnerabilities remained exploitable under the reference design.
- Across the tested configurations, interface design affected exploitability more than agent choice, moving retention of attacks from 39% to 95%, against at most 4.5 points across agents.
- No case-level loss in the reference configuration was attributed to agent refusal or input normalization. In one case, the agent completed an attack by supplying calls the attacker had omitted.
- Some restrictive interfaces also limited legitimate workflows.
The limits matter. This is a benchmark of web applications, not law-firm intake systems. It measured vulnerability exploitation, not lead capture, and it tested three agents under specific configurations. It does not tell us how a firm's intake form, CRM or conflicts check would behave. The abstract supports a narrower point: in those tests, the design of the exposed operations was a larger lever than the choice of agent. The abstract also names a tradeoff between reducing attack exposure and preserving legitimate function. Whether the same pattern holds for intake systems is untested; we treat it as a hypothesis worth checking.
Why this may be a revenue question, not only a security one
Intake is where a firm's marketing spend, referral relationships and reputation turn into matters or don't. A vendor page from AI Automation Studio argues that firms mostly lose enquiries to slow first response, incomplete information and unowned handoffs, not to weak services. That page is undated vendor material aimed at UK firms, with no measurements in the excerpt we have. Read it as one practitioner's framing, not as evidence of how often this happens. Still, the three failure points it names can be tested inside any firm.
Our inference is that opening intake to agents could affect each of those points, in ways that may cut both ways:
- Response speed. A machine-readable intake might acknowledge and structure an enquiry at any hour. That is a possible gain, to be verified against your own timestamps.
- Information completeness. An agent may supply fields a person would skip, but it could also supply fields the firm never intended to accept. The VELA case where an agent supplied calls the attacker omitted is a security example of agents filling gaps; whether intake agents behave similarly is an open question for your own testing.
- Ownership. If an agent-submitted matter lands in a queue nobody watches, the leak could be silent. Whether that happens at your firm is something only first-party data can show.
The hypothesis worth testing is that the exposed operations define both the risk and any leakage. If the interface allows an outside agent to read status, change a submission, or trigger a conflicts check without a named owner, each of those may be a path where facts or matters could be lost, exposed or mishandled.
A five-step acceptance test before opening intake to agents
This is a working method, not a standard. We recommend running it before any agent-facing intake goes live, and adapting it to your systems.
- Inventory the operations, not the tools. List every action an outside agent could perform: create an enquiry, attach a document, read status, edit a prior submission, request a callback. For each, write who on the firm side owns the result. We recommend treating any operation with no owner as a candidate for removal or a human gate.
- Start with the narrowest interface that still serves a real client task. If the preprint's pattern carries over to intake, which is our assumption and not a finding, then removing required operations or limiting input control could matter more than swapping models. The preprint's caution applies too: restrictions that break legitimate workflows have a cost. Decide in advance which client tasks must survive.
- Separate triage from advice and from acceptance. The AI Automation Studio page draws the line this way: automation handles intake administration and triage, while legal advice, final matter acceptance and sensitive exceptions stay with a human. We recommend encoding that line in the interface itself, so an agent cannot reach an operation that implies acceptance.
- Test with hostile and sloppy inputs. Send malformed fields, duplicated submissions, conflicting facts and oversized attachments through the agent path and the human path. Record what each does. Do not assume the agent will refuse or normalize bad input; in the preprint's reference configuration, no case-level loss was attributed to refusal or normalization, and we suggest not assuming intake agents differ until you have tested them.
- Trace facts end to end. Pick a sample of test enquiries and follow each fact from first contact to the person who reviews it. Our earlier post on a 30-to-50-inquiry trace test sets out a way to do this. Run it on the agent path as a separate lane so you can compare it against your existing channels.
What to log, and what to ask vendors
Intapp's stated position, that the same restrictions and audit requirements apply to the AI as to people, is in our view the right question to carry into any vendor conversation. We recommend asking to see it demonstrated, not described. Specifically:
- Can the vendor show a per-action record of what an agent submitted, read or changed, tied to the matter and the requesting party?
- When restricted information is requested through the agent path, what does the response look like, and is that tested?
- Which operations can a firm disable without rebuilding the workflow?
- Who is notified when an agent-originated enquiry is incomplete or ambiguous?
For your own record, we suggest capturing time from agent submission to first human touch, the share of submissions missing required facts, and the number that reached a named owner. These are first-party measures. Until you have them, any claim about leakage, positive or negative, is speculation.
The part nobody can yet claim
It is tempting to read General Legal's MCP server or Celeste's intake playbooks as proof that agent-facing intake works. The sources do not support that. One is a conversation with a founder, the other a product announcement with a customer expectation. The security preprint, for its part, reports that in web applications the interface drove exploitability more than agent choice. Our tentative inference is that exposure in agent-facing intake may likewise be a design decision made by whoever defines the interface, and that fewer, better-bounded operations may be a stronger control than picking a more careful model. That remains untested for intake.
Our recommendation for a managing partner is modest. Before any agent-facing intake goes live, someone should be able to state in a sentence what an outside agent can and cannot do, who owns each outcome, and how the firm would find out if a matter went missing. If that sentence cannot be written, we would treat the interface as not ready, regardless of which agent or vendor sits behind it.