EASM One for Universities
Applicants, students, faculty and leadership answered at any hour, in their own language, across admissions, academics and the front desk.
Explore the deployment for UniversitiesEASM One · Infrastructure
The foundationunder everyEASM product.
EASM One gives every product one sign-in, one record of each person, one knowledge base, one security model and one audit trail. It connects to your ERP, SIS, CRM, LMS, phone system and documents, and a deployment combines the products an organisation needs.
EASM OneInfrastructure specificationIn production- Products
- 8, on one infrastructure
- Channels
- Web chat, WhatsApp, voice, phone lines, kiosk, internal apps
- Languages
- English, Urdu, Punjabi, Sindhi
- Shared
- 1 sign-in · 1 record per person · 1 audit trail
- Connects
- APIs · read-scoped database connectors · telephony bridge
- Hosting
- Your servers · a private cloud · EASM Clouds
In production at universities today
01 The cross-section
Five layers, from the conversation down to your systems of record.
- L5Channels
Where people ask. Every channel reaches the same infrastructure, so an answer on WhatsApp matches the answer at the front desk.
- L4Products
Eight products, used alone or together. None of them carries its own sign-in, records or audit: they inherit them from the layer below.
- L3EASM One core
Built once and shared by every product: identity and roles, one record per person, approved knowledge, the rules assistants follow, and the audit trail.
- L2Connections
Your systems connected once, through each system's API, a read-scoped database connector or a telephony bridge. Read-only unless you allow more.
- L1Your systems and hosting
Nothing is migrated and nothing is replaced. EASM One runs on your servers, a private cloud or EASM Clouds, with data kept where you decide.
02The agent layer
Agents that finish the work, inside limits the system enforces.
A chatbot replies. An EASM agent reads the records a person is allowed to see, calls the tools their role permits, checks its answer against the evidence and completes the task, or hands it to a person who can.
A typical chatbot
- Question
- Reply from a script
- Your staff still log in, check and do the work
An EASM agent
- 1Question
- 2Checks your records
- 3Answers, with the source
- 4Completes the task
- 5Reports and keeps a record
One agent turnThe same loop on chat, WhatsApp, the phone, the kiosk and the portal.
01UnderstandIntent and language
02PlanRole-gated tools
03ActRecords, knowledge, tools
04CheckEvidence and answer guards
05Answer or hand overCited, or to a person
06RecordEvery turn audited
- 01Understand
The request and its language are classified before a model is called. A question that only needs approved knowledge skips the tool loop entirely.
- 02Plan
The agent is shown only the tools this person's role allows. Students, faculty and staff each have their own set, and private tools stay hidden until identity is verified.
- 03Act
Live records, approved knowledge and your own configured tools, called in parallel, within a fixed budget of tool calls per turn.
- 04Check
Retrieved passages are reranked and gated on confidence. Answers about grades, fees and academic records are checked against what the tools returned.
- 05Answer or hand over
Answered with its source, or handed to the right person with the conversation and the record attached.
- 06Record
The question, the tools called, their timing and the answer are written to the audit log on every turn.
03Tools
29 built-in tools, and any system you connect.
Agents act through tools, never through raw access. Each tool belongs to a category, each category to the roles allowed to use it, and every call is audited. Built-in connectors read live from PeopleSoft Campus Solutions and Moodle.
KnowledgeEveryone
search_knowledge_baseApproved sources: hybrid search, reranked, cited to the page
Student recordsStudents · verified
get_my_degree_progressCompleted and remaining courses, computed from the transcriptget_my_fee_vouchersVouchers and payment statusget_my_attendanceAttendance by class, against the minimumget_upcoming_deadlinesAssignments and deadlines from the learning system
Faculty workflowsFaculty · verified
get_faculty_class_studentsClass lists by sectionget_student_class_attendanceAttendance for a classget_student_class_resultResults for a class
Staff toolsStaff · verified
search_staff_directoryPeople, departments and offices
Your systemsConfigured in EASM Automation
Any system with an API becomes a tool through a guided setup: inputs, a test, then live. Reading is the default. A tool that changes something runs as an audited, idempotent action, and only for a verified person.
04Voice agents
On the phone, the answer waits for the evidence.
A spoken answer cannot be taken back. So on calls, the decision to ground a turn belongs to the system, not the model: the caller hears an institutional fact only once it has been found in your approved sources.
- Held, never released ungrounded. If evidence does not arrive in time, the held answer is discarded and the caller is offered a follow-up from the office instead of a guess.
- Never silent. Every hold is bounded, so the caller is never left waiting on dead air.
- Reviewed after the call. Calls are reviewed once they end, and any follow-up is drafted from the evidence and matched to where the person already stands.
- On the lines you have. Calls reach EASM through a bridge to your existing phone exchange; numbers and extensions stay as they are.
- Caller asks
“What is the fee for BS Computer Science?”
- Retrieval starts at once
The turn is classified as needing an institutional fact; evidence is fetched without waiting for the model to ask.
- Spoken answer held
The agent's audio for this turn is held until a ground source exists.
- Released with evidence
The answer is released, or replaced with a grounded one.
If no evidence in time
“I’ll have the admissions office confirm that and send it to you.”
05Guardrails
Eight things an EASM agent cannot do.
None of these depends on the model behaving well. Each is enforced in the code around it, so it holds whichever model is answering.
choose whose record it reads.
The person is taken from the verified sign-in and injected into every tool call. The model never supplies it.
see private tools before identity is proven.
A website visitor, a WhatsApp number or a phone caller alone is not a verified identity. Personal tools stay withheld until it is.
change a record for an unverified person.
A tool that changes something runs only for a verified identity, and is refused twice: when tools are offered, and again when it executes.
send the same change twice.
Every change is an idempotent action: asked again in the same session, it returns the first result and sends nothing.
loop without end.
Each turn has a fixed budget of tool calls, so no request can run away with your systems.
do the arithmetic itself.
Degree progress, remaining credits and similar figures are computed by the system from the records. The model presents them.
reach inside your network.
Configured tools are checked when they are saved and again on every connection, and redirects are never followed.
read a stored credential.
Connection credentials are sealed with AES-256-GCM. No screen ever shows the opened value; only its last characters.
06A turn, traced
One question, through the whole loop.
Every answer follows the same path, whichever product and channel the question arrives on. This is that path for a single WhatsApp message.
- ChannelWhatsAppQuestion received“Is my hostel fee cleared?”
- UnderstandIntent and languageClassified as a personal fee question before any model runsPersonal data · English
- CoreIdentitySender matched to a verified student recordIdentity comes from the sign-in, not from the model
- PlanToolsOnly the tools a student may use are put in front of the agentFee records · knowledge
- ActFinance systemFee vouchers read live, read-onlyCalled in parallel with the policy search
- ActKnowledgeFee policy retrieved, reranked and passed the confidence gateFee Policy · section 3.1
- CheckAnswer guardAnswer checked against the voucher the tool returnedAmounts and dates must match the record
- ChannelWhatsAppAnswer sent with its sourceCleared on 12 September · next voucher 1 December
- RecordAuditThe turn, every tool call and the answer loggedReviewable by administrators
07Built once
Built once. Inherited by every product.
The parts every product needs live in the infrastructure, so a new product, or a project we build for you, starts with every column already filled.
| Product | Sign-in and roles | Person record | Knowledge | Rules and tools | Audit trail | Hosting choice |
|---|---|---|---|---|---|---|
| EASM Support | ||||||
| EASM Knowledge | ||||||
| EASM Forms | ||||||
| EASM Calling | ||||||
| EASM Ask | ||||||
| EASM Kiosk | ||||||
| EASM Marketing | ||||||
| EASM Automation |
Identity and accessSingle sign-on, roles and departments, and who may see what, once for every product.
One record per personChat, WhatsApp, calls, forms and the portal joined into one history for each person.
The AI layerAnswers only from approved sources, with the source shown; every action logged.
ConnectionsYour systems connected once and used by every product, read-only unless you allow more.
Hosting choiceYour servers, a private cloud or EASM Clouds, with data kept where you decide.
OperationsStaged releases, monitoring and usage reporting across every product.
08Connections
Over the systems you already run.
Connected once, through each system's API, a read-scoped database connector or a telephony bridge, and used by every product. Your IT team decides what each connection can read and write.
- 01Connect
Connectors read from your systems of record and your document libraries. Nothing is migrated and nothing is replaced.
- 02Understand
Every request carries the identity and role of the person asking. EASM retrieves only what that person is allowed to see.
- 03Act
EASM answers, updates records, books appointments, routes cases and follows up, and each action is logged.
EASM One09Invariants
Five rules the infrastructure never breaks.
They hold for every product, every channel and every deployment, because they are enforced in the layer underneath, not by each product.
- 01
Access follows your roles.
Every request carries the identity and role of the person asking. EASM retrieves only what that person is allowed to see.
- 02
Answers cite their source.
Assistants answer only from approved sources, and every answer shows the document, section and page it came from.
- 03
Reading is the default.
Connections are read-only unless you allow more. A change to a record needs a verified person and goes through your workflow.
- 04
Every action is logged.
What was asked, which systems were read, what was answered and what was changed, kept for review.
- 05
Your data stays where you decide.
On your servers, a private cloud or EASM Clouds. Personal records are read live and never stored as knowledge.
10Deployments
One infrastructure, deployed by industry.
A deployment combines the products an organisation needs, configured to its own systems. Universities run it in production today.
EASM One for Hospitals
Patient calls, messages, registration and reception for hospitals and clinics, handled on every line at once.
Explore the deployment for HospitalsEASM One for Enterprises
Customers and employees talking to your systems in plain language, across every branch and every channel.
Explore the deployment for Enterprises