How to Build a Legal Research Agent Without Sharing One User's Login
A legal research agent can be useful only if access stays tied to the person using it. Descrybe Legal Engine Python is designed around per-user OAuth so apps, scripts, and local agents do not have to turn one person's Descrybe account into a shared team credential.
The tempting shortcut
When someone builds a legal research agent for a team, the shortcut can look simple: connect one Descrybe account, put that token on the server, and let everyone use the agent through that account.
That is not the right shape for a shared app. It blurs who is using the service, who has access, and which subscription or entitlement is being used. It also makes it harder to reason about account boundaries later.
The intended pattern
The intended pattern is per-user OAuth. Each human user connects their own Descrybe account. When that user asks the app or agent to perform legal research, the app uses that user's Descrybe connection for the Descrybe Legal Engine calls.
For a 20-person firm app, that means 20 app users, 20 Descrybe OAuth connections, and Descrybe calls attributed to the actual user making the request.
Why this matters for legal research
Legal research is often tied to sensitive questions, client matters, drafts, citations, and internal work product. Even when the tool is only retrieving public-law sources, the request itself may reveal what someone is researching.
Per-user OAuth keeps the access boundary closer to the real user. It avoids treating one person's login as a team utility account and gives the app a cleaner way to ask each user to connect, disconnect, or refresh their own access.
How the SDK supports this
Descrybe Legal Engine Python includes a command-line tool and Python client for local scripts, agents, and web apps. For local single-user tools, dle login can create a local token profile for that user. For web apps, the app should load the current user's Descrybe OAuth connection and build a client for that user only.
The SDK also includes coding-agent instructions so a developer can hand the OAuth rules and validation checklist to a coding assistant before building a Descrybe-enabled app.
- Use dle login, dle doctor, and dle list-tools for local single-user validation.
- Use per-user OAuth connections for shared web apps.
- Store refresh tokens encrypted in the app database and keyed to the app user.
- Build the Descrybe client for the current user, not for the whole firm.
- Use the simple web app example as a compact reference for the OAuth pattern.
What not to do
- Do not place one user's refresh token behind a shared app for everyone.
- Do not ask one lawyer or admin to connect Descrybe and silently proxy all other users through that account.
- Do not solve login problems by copying tokens into environment variables for a team app.
- Do not confuse app login with Descrybe authorization; your app user and the Descrybe-connected user need to line up.
A safer build checklist
- Decide whether the tool is local single-user or multi-user web app.
- For local tools, validate with dle doctor and dle list-tools without printing secrets.
- For web apps, create a Descrybe OAuth connection flow for each app user.
- Store refresh tokens encrypted and scoped to the app user.
- Call Descrybe Legal Engine with the current user's access token.
- Show users when their Descrybe connection is missing, expired, or needs to be refreshed.
- Keep legal source review in the workflow before relying on output.
Where workflow packs fit
The workflow pack can help define what the agent should do once it has access: create a research roadmap, find authority, or audit citations and quoted language. The Python SDK helps the app connect safely. They are complementary layers.
A good legal research agent usually needs both a clean access model and a source-aware research pattern.