Education and EdTech
Answer every student, even at term start.
Agents, data platforms and resilient systems on Google Cloud for universities, districts and EdTech, with student records in your own project.
Agent workspace · Student exceptions
An illustration of an agent we build
Queue
- Aid appealApproved
- Late dropPreparing
- Transcript holdWaiting
- Housing requestWaiting
Aid appeal
ApprovedReads
- Student record
- Published policy
- Deadlines
The agent prepares
- Finds the policy
- Checks the record
- Drafts the case
Ready for review, with every fact linked to where it came from.
A person decides
Staff approve
Answer sent
- Google Cloud Partner
- Databricks Partner
100+
Projects delivered
45+
Enterprise clients
8
Industries served
98%
Client satisfaction
What we build
Answer students where they wait longest.
Pick a workflow and watch it run, from your records to the staff member who decides.
Answers from admissions, aid and the registrar
Enrollment, financial aid and student services teams
Answers routine questions from your policies and the student's own record.
Reads
- Published policies
- Deadlines
- Student record
The agent prepares · Gemini Enterprise
- Finds the policy
- Checks the record
- Answers or routes
Hands over · Student answer
- Policy cited · Aid policy 3.2
- Record checked · FAFSA on file
- Answer or handoff · Sent, with source
A person decides · approved
Staff handle exceptions
Then
Student answered
Built on · Gemini Enterprise · Agent Platform · BigQuery
Read every workflow as text
Answers from admissions, aid and the registrar
Enrollment, financial aid and student services teams
The agent answers routine questions from your published policies and deadlines, and from the student's own record once they sign in, and hands the rest to the right office with the question attached.
A person decides: Staff handle every exception. The agent never changes a record or awards aid.
We measure: Questions answered the same day, and calls and emails per office in peak weeks.
Built on: Gemini Enterprise, Agent Platform, BigQuery
Early alerts for students who are slipping
Advisors and student success teams
Attendance, grades and LMS activity come together into a weekly list of students who may need a conversation, each with the reasons, so advisors can spend the week on conversations.
A person decides: An advisor decides who to contact and how. Nothing happens to a student automatically, and the signals are checked for bias across student groups before the list is used.
We measure: Students contacted each week, and how many of them return next term.
Built on: BigQuery, Looker, Agent Platform
Course materials made accessible
Accessibility offices and instructional designers
Lecture video gets captions, images get draft alt text, and documents get checked for structure, so the backlog of course materials moves before the ADA Title II deadline that applies to you.
A person decides: A person reviews every caption and alt text before it is published.
We measure: Materials remediated, and the backlog left before the deadline.
Built on: Gemini, Speech-to-Text, Document AI
A student data warehouse
Institutional research and data teams
SIS, LMS and assessment data come together in BigQuery, with row and column access set by role, so reports and dashboards draw on one governed copy of the student record.
A person decides: Your data governance group approves each new use of student data.
We measure: Time to produce a report, and reports that agree with each other.
Built on: BigQuery, Knowledge Catalog, Looker
Answers for teachers and staff
Teachers, HR and IT service desks
Staff ask about policy, systems and procedures and get the answer from your own handbooks and knowledge base, with the page it came from. Districts on Google Workspace for Education can start from the Gemini for Education tools they already have.
A person decides: The policy owner keeps the source documents current.
We measure: Service desk tickets per week, and time to answer.
Built on: Gemini Enterprise, Gemini for Education
Backups you can restore from
CISOs and infrastructure teams
Student systems get backups an attacker cannot delete, multi-factor sign-in for every admin, and a restore that has been rehearsed before anyone needs it.
A person decides: Your security team owns access and runs the restore drills with us.
We measure: Time to restore a system in a drill, and backups verified each month.
Built on: Backup and DR Service, Cloud Identity, Security Command Center
Platforms that carry term start
IT and EdTech engineering teams
Registration, the LMS and lecture video scale for enrollment, the first week of term and exams, and shrink for the quiet weeks. Cutovers happen in summer, so the next term starts on the new platform.
A person decides: Your team sets the change freeze around term dates.
We measure: Uptime and page speed in the first week of term, and cost in the quiet weeks.
Built on: Cloud Run, Google Kubernetes Engine, Cloud CDN
Each customer's student data kept apart
EdTech CTOs and privacy leads
Each district's or university's data sits in its own partition, access follows the data agreement you signed with them, and you can show any customer exactly who read their students' records.
A person decides: Your privacy lead approves how each customer's data agreement is set up.
We measure: Time to answer a customer's privacy questionnaire, and access exceptions found in review.
Built on: AlloyDB, Cloud KMS, Cloud Logging
The academic year
Plan the platform around the calendar.
Pick a point in the school year to see what carries the load.
Systems that carry it
- LMS
- Student records
- Analytics
- Identity
- Lecture video
Drawn on a typical US school calendar. We redraw it for your term dates.
Proof from neighboring fields
The closest work we have shipped.
We have not published an education case study yet. The closest two: subtitles and tags generated across a media archive, and form onboarding where a person approves every output.
Media archive
Editors moved from writing metadata to reviewing it
A Chicago-based media archive and licensing company
10-20x
more content tagged per editorial hour
Media · AI · Google Cloud
Read the study
Public sector software
Client onboarding cut from six months to weeks
A government and non-profit health and human services case management platform
80 to 90%
of form onboarding effort automated
Public Sector · Document AI · Google Cloud
Read the study
What is changing
Schools face more attacks, and the accessibility deadline is set.
Each item links to its source, ready for your cabinet or board.
2025-26
11,600+
cyber incidents escalated by schools in the 2025-26 school year
Backups and restores need testing before anyone needs them.
CIS, MS-ISAC and CoSN, The State of K-12 Cybersecurity 20262026
33%
of K-12 organizations have a formal AI policy
Tools that answer from your own policies give it something to point to.
CIS, MS-ISAC and CoSN, The State of K-12 Cybersecurity 202626 Apr 2027
26 Apr 2027
until the ADA Title II deadline for large public entities
Smaller entities and special districts follow in April 2028.
ADA.gov, fact sheet on the Title II web and mobile accessibility rule
Read every item in full
2025-26
Schools escalated more than 11,600 cyber incidents.
That is the count CIS, MS-ISAC and CoSN report for the 2025-26 school year. Student systems need backups and restores that have been tested before anyone needs them.
2026
About a third of K-12 organizations have a formal AI policy.
Staff and students are already using AI. Tools that answer from your own policies, with a person responsible for each source, give the policy something to point to.
26 Apr 2027
The accessibility deadline is set for web and mobile.
Under the ADA Title II rule, state and local governments serving 50,000 or more people must meet WCAG 2.1 AA by 26 April 2027, and smaller ones and special district governments by 26 April 2028. Public colleges and districts should confirm which date applies to them.
The engineering underneath
Try to make it decide.
Pick a request a student might make. Watch what the agent does, and what lands in the audit log.
As Student
Student services agent
Signed in as Student
No tool here can change a student record. It explains the drop deadline and connects the student to the registrar.
Audit log
- refused · change_record · student
A simulation of the controls we build into every education agent. It is not a live system.
- Runs inside your own Google Cloud project
- A person approves what the agent prepares
- Every action written to the audit log
- Scored against your past cases before launch
Read the requests and the engineering behind them as text
Student: Drop me from Biology 101
Refused. No tool here can change a student record. It explains the drop deadline and connects the student to the registrar.
Student: Raise my aid award
Refused. Aid decisions stay with the financial aid office. It shows the appeal process and its deadline.
Student: When is the tuition deadline?
Cited. It quotes the date from your published calendar and links to the page.
Student: Show me my classmate's grades
Filtered. Access is set by role and by record. Other students' records returned: 0.
Access set by role, row and column
It prevents: A report or an agent showing one student's record to someone with no reason to see it. You check it: Access rules live in code, and every read of student data lands in the audit log.
Answers grounded in your policies
It prevents: An agent inventing a deadline, a fee or an aid rule. You check it: Every answer cites the policy page it used, and questions it cannot answer go to staff.
Records that only people change
It prevents: An agent enrolling, dropping or awarding anything because a student asked nicely. You check it: No tool can change a student record. Requests for one are refused and logged.
Tested before term starts
It prevents: Finding the limit of the registration system in the first hour of enrollment. You check it: You see the load test against last term's peak before the change freeze.
How we start
We begin in the quiet weeks, with one workflow.
Most institutions start with one office or one system, in the quiet weeks.
First
A call with an engineer
Bring one workflow and its systems.
Fixed fee
Discovery
A written plan, or a written no.
Day 0 to 30
Build and test
Starts once the data agreements are in place.
Day 30
One workflow live
On Gemini Enterprise, at a fixed fee.
After
Run it, or hand it over
Your call. The next one reuses it.
We need from you
- An office or system owner
- A few hours a week from staff
- Data agreements in place
- Last term's questions
What can slow it down
- Term dates: summer cutovers
- Data agreements: a written data flow
- Limited SIS APIs: checked in discovery
You keep
- The code, in your repo
- The test set and its scores
- Runbooks and the audit log
- Your Google Cloud project
Read each step in full
A call with an engineer
Tell us the workflow and the systems it touches. A senior engineer replies, usually within one business day, and says plainly if it is not a fit.
A fixed-fee discovery
We sit with the people who do the work, check what data the system can reach, and write down what we would build, how we would test it and what it costs. It ends with a written recommendation, and sometimes the recommendation is not to build.
One workflow live in thirty days
Once the data agreements are in place, we put one workflow live on Gemini Enterprise in thirty days, at a fixed fee, tested against last term's real questions. Platform moves are scheduled for the quiet weeks.
Run it with you, or hand it over
We stay to run and improve it, or your team takes it over with the code, the runbooks and the test set. Either way, the next workflow reuses everything underneath.
What can slow it down, and what we do about it
- Term dates and change freezes. We schedule cutovers for the quiet weeks.
- Data sharing agreements and approvals. We bring the data flow written down for your privacy office.
- Student information systems with limited APIs. We confirm what is reachable during discovery.
Frequently asked
The questions we hear first.
Student data stays in your own Google Cloud project, with access set by role and every read logged. We build to your institution's privacy policy and the agreements you have in place, and we avoid sending student records to any model or service those agreements do not cover.
It answers only from your published policies and the student's own record, cites the page it used, and hands anything it cannot answer to staff. We test it against real questions from last term before it goes live.
Yes. We size it for your busiest week, load-test against last term's peak, and let it shrink for the quiet weeks so you do not pay for peak all year.
With one workflow where students or staff wait longest, and a fixed fee. If the first step is an agent, we put it live on Gemini Enterprise in thirty days and test it against your own questions first.
Our teams work from the US, London and Ahmedabad. Access to your data is granted per person, through your identity provider, inside your own Google Cloud project, and every access is logged. If your policy limits where people who see student records can sit, tell us on the first call and we will say plainly whether we can staff to it.
We test against last term's real questions and the answers staff gave, score every run, and show you the scores. The same test set runs on every change, and a change that lowers the score does not ship.
You do. The code sits in your repository, everything runs in your own Google Cloud project, and the test set and runbooks are yours. Each step ends with something you keep, so you can stop after discovery with the written recommendation, or after the first workflow.
Tell us when your next term starts.
A senior engineer replies, usually within one business day.