Built from the needs
of a real application.
Core’s specification began in the Legalfy repository. Building an application around documents, context, and review exposed the infrastructure an agent needs beyond a model call.
The history, precisely.
Legalfy brings documents, matter context, drafting, and user decisions into one product. The platform specification originated in that repository; Core is now implemented in its own repository as a general-purpose platform. Legalfy’s source and interaction patterns informed Core’s client sessions, shared context, document access, and embedded experience.
The reusable boundary is deliberate: Core manages execution and interaction, while Legalfy keeps its legal-domain logic, document APIs, and business authorization.
Why these capabilities belong together.
The work extended across the application: carry the acting user into every document read, keep a draft alive beyond a browser page, share the right context, and put questions and decisions back in front of people. Each connection required application code and failure handling.
| What Legalfy required | Reusable Core capability | What stays in the application |
|---|---|---|
| Read document evidence in the acting user’s context. | Signed client identity on tool calls; knowledge collections for indexed reference material. | Select permitted content and check document permissions on every business API read. |
| Let a team share work on a matter. | Audience-scoped groups and conversation sessions. | Map firms and matters to scope, and enforce restricted matters through access controls. |
| Continue drafting after a page closes. | Recorded runs, resumable work, and server-started runs for a client. | Define drafting rules, preserve domain records, and decide when to start or cancel work. |
| Ask a question or review a proposed action before proceeding. | Workflow waits, approvals, and pending-request UI components. | Choose reviewers and implement the business action and its permission checks. |
| Show useful progress, answers, and files in the product. | React hooks and components for progress, pending requests, results, and files. | Compose the product pages, source navigation, uploads, and domain-specific editing. |
A new application can evaluate these implemented capabilities through the SDK, console, and embedded components. See preview availability for access and the planned features.
From your app’s sign-in to a recorded result.
The supplied React sample is a small Core integration with its own Node server. Its full source and setup instructions are available in the developer docs. It provides a concrete implementation of the boundary described above.
- Prepare the environment. Allow the sample’s website origin, create an operator API key, and offer a published agent or workflow through Client apps.
- Bridge your sign-in on the server. The sample’s
POST /sessioncallsclientSessions.createand returns the browser session. Replace its demonstration identity function with your application’s authentication. - Connect the page.
connectClientsupplies the client toJwtsonProvider. Session renewal returns through the application server so current sign-in still matters. - Start work and follow it.
useStartstarts the selected target;useRunfollows its progress.PendingRequestsrenders questions and approvals, andResultFilespresents delivered files. - Inspect the settled outcome. Review the final run state, result, and earlier runs or chats. Streamed text can change before the result settles.
The sample needs a running Core environment and the supplied packages. Its sign-in function is a development example, and its local browser tests exercise the integration with a deterministic model. The public marketing demos remain illustrative browser scenarios.