01
Conversational agent
A person starts the conversation. The agent answers in natural language from your grounded knowledge, returns rich card-based responses with suggested actions, and can execute real operations mid-conversation.
One platform. Three kinds of agent. Your systems.
Soria is where you build, ground, publish and govern AI agents — conversational, event-driven and scheduled. Configuration, not a custom build: the same product runs a student assistant, an IT service desk and a nightly reconciliation job.
What Soria is
Soria is a multi-tenant AI agent platform built by LS2 Innovation. An organisation defines agents — their instructions, their model, their knowledge sources, the tools they may call and the channels they appear on — and Soria runs them, versions them, and records everything they do.
It is model-agnostic: the model, its parameters and its processing region are configuration, not architecture. It has been running in production against real operational systems since before it was offered to clients, which is why the capabilities below are product features rather than a roadmap.
- Multi-tenant
- Model-agnostic
- Retrieval (RAG)
- Tool calling
- MCP servers
- Cron & webhooks
- Versioned agents
- Full audit trail
Agent types
Three ways an agent gets invoked
Same engine, same tools, same audit trail. What differs is what wakes the agent up.
02
Webhook agent
An external system starts it. An inbound event — a record created, a meeting recorded, a form submitted, a team provisioned — triggers an agent that runs its instructions and calls the tools it needs.
03
Scheduled agent
The clock starts it. Every thirty minutes, hourly, daily, weekly, on a given weekday or monthly — or on a cron expression — with run history and status per execution.
Instructions are versioned like code
Every agent and every automated task keeps a history of its prompt versions. You can see what changed, who changed it, and restore a previous version — which is what makes it possible to run an agent in a regulated environment at all.
Knowledge & grounding
Agents answer from your content, not the internet
Every agent is attached to one or more vector stores. Nothing enters an answer that didn't come from a source you loaded and approved.
- Document vector storesUpload your files — policies, procedures, regulations, guides — with version history on each file.
- SharePoint-backed storesIndex a SharePoint site or specific document libraries directly, so the agent follows content your teams already maintain.
- Integration storesKnowledge pulled from a connected system rather than a file, kept in sync as the source changes.
- Several stores per agentA default store plus additional ones, so one agent can span a public knowledge base and a restricted internal one.
- Past conversations as knowledgeOptionally let resolved conversations feed the knowledge base, so the agent improves from real questions.
- Fine-tuning when it earns its placeSupported for the narrow cases where retrieval isn't enough — tracked as a managed job, not a black box.
Tools & actions
Agents that do things, not just describe them
Answering is the easy half. Soria agents call defined tools to read and change state in your systems — under permissions you control.
- Custom tool definitionsDeclare a tool with a JSON schema and its implementation; the agent calls it when the conversation calls for it.
- Tool groups and per-tenant scopingGroup tools as standard or application-specific, and grant each organisation only the groups it should have.
- MCP server connectionsAttach Model Context Protocol servers, with OAuth, to reach whole tool ecosystems without writing a connector per system.
- Per-agent authenticationAn agent can authenticate the person it's talking to before acting on their behalf, against your user-info endpoint.
- Rich responsesAdaptive cards, suggested actions and file attachments — so a result is something a person can act on, not a wall of text.
- OAuth/OIDC application clientsYour own applications call Soria's API with scoped credentials, so agents can be embedded anywhere.
Channels
Published where people already are
The same agent, the same knowledge and the same tools — surfaced on whichever channel the audience actually uses.
Microsoft Teams
A first-class Teams app for staff and students who live in Teams all day, with adaptive cards and proactive messages.
Web chat
Embed the agent in a portal, an intranet, your LMS or a public page — authenticated or anonymous, depending on what the agent is for.
Your own application
Call the API directly with a scoped OAuth client and build the interface yourself, keeping Soria as the agent runtime behind it.
Multilingual by default
Welcome messages and agent behaviour are defined per language, so French, English and other languages are one agent, not three.
Event channels
Inbound webhooks let any system start an agent — and outbound actions let the agent reply into Teams, email or a ticketing queue.
Scheduled delivery
Reminder campaigns, digests and reports go out on a schedule, to the channel the recipient reads.
Build & publish
From draft to production without a deployment
Agents are configured in the console and published as versions. Changing what an agent says never requires a release.
-
Configure
Name, description, icon, instructions, model, temperature and top-p; attach knowledge stores, tool groups, MCP servers and authentications.
-
Test as a draft
The working version is separate from the published one. You exercise it against real questions before anyone else sees it.
-
Publish a version
Publishing promotes the draft. The previous published version remains on record, and prompt history stays attributable.
-
Observe and correct
Conversation history, task run logs and activity logs show what actually happened — including the questions the agent could not answer, which become your content backlog.
Administration
Multi-tenant, role-based, delegated
Soria was multi-tenant from its first deployment. Each organisation is isolated, configured on its own, and administered by its own people.
| Role | Can do | Cannot do |
|---|---|---|
| End user | Talk to the agents published to them, on the channels they have access to. | See anyone else's conversations or data. |
| Observer | Browse published content and agent behaviour to help someone else; sign in by SSO or invitation, with no account needed in your LMS. | See individual end-user data. |
| Content owner | Maintain the knowledge sources and content their team owns, and submit changes for validation. | Touch another team's content or platform settings. |
| Organisation administrator | Configure agents, tools, roles, permissions, features, branding and integrations; publish versions; read logs and dashboards. | Reach another organisation's data or configuration. |
| Network administrator | Maintain shared templates and tool groups, and move content between organisations. | Read individual end-user data in any organisation. |
Granular feature permissions
Access is granted feature by feature to roles and groups, not as a blunt admin flag. Institutional SSO maps your directory groups onto those roles.
Delegated content management
The teams who own a service maintain its content directly, with drafts, validation before publication, version history and one-place-to-change propagation.
Configuration per organisation
Agents, tools, languages, branding and feature entitlements are held per tenant — including per education type, for institutions running continuing education or professional training alongside regular programs.
Guided setup and release notes
A setup checklist walks a new organisation through onboarding, and in-product release notes — translated — tell administrators what changed.
Logs & analytics
Everything an agent does is on the record
Four distinct log streams, each queryable and exportable — because in a public body, "the AI did it" is not an acceptable answer.
- Audit logEntity changes, permission changes and administrative actions — timestamped and actor-tagged.
- User activity logWho signed in, what they opened, what they changed.
- Task run logsEvery webhook and scheduled execution with its status, so a failed job is visible rather than silent.
- Conversation historyRetained per your policy, and usable — with consent — to improve the knowledge base.
On top of those: usage and completion rates, which resources people actually reach, frequent themes, peak moments, satisfaction after a conversation, and the requests nobody could answer — aggregated and anonymised, so you get a picture of demand without building dossiers on individuals.
Security, hosting & data lifecycle
See the console, not a slide deck
Thirty minutes inside the product: an agent configured, grounded on a document you bring, calling a tool, and publishing a version.
Book a Demo