AI at Inneall
We run our own company
on the AI we sell
An AI engineer on our service desk, an agent watching 31 production services, and connectors that let AI use our Moodle, CRM, student records and this website. All of it in production, all of it governed, none of it a demo.
Platforms we run and connect for colleges
Built for ourselves first,
which is how we know it works
A real ticket, answered by Lugh
A college reported a Moodle user locked out after a long course copy. Lugh went into the live system, found the stuck session, cleared it and replied. Names changed; nothing else.
"Hi [name], [the user] was stuck after a long module reuse on a test course, which left her Moodle session locked so she could not get back in. I have cleared that stuck session and checked that her account is active and the login page is working. Can you give that another try now?
Lugh, Service Desk, Inneall. Lugh is an AI-powered member of our support team."
His internal note on the same ticket, written for our engineers: cause, certainty 92%, verification that the login page returned 200 and single sign-on redirected, what was changed, and the three ISO procedures he checked first. On a different ticket he recognised a request for new automated emails as a change rather than a fault, said so to the customer, and sent the account manager a four-line note: "Change, not a fault. Size: days. No work until the client approves."
Read the Lugh case studyWhat is running today
Colleges ask us whether AI can work safely with the systems they already run. Rather than answer with slides, we built it for ourselves first. Everything below is live in our own operation.
- Lugh, an AI engineer with his own Jira login and email, working real support tickets under his own name
- The Ops Agent, a night watch over 31 production services that can only run commands a person has read and approved
- Model Context Protocol connectors that give AI governed access to Moodle, Salesforce, our student systems, our management dashboard and this website
- AI coding agents that write, test and ship a growing share of our code, inside the same review process as our engineers
- This website, rebuilt by an AI agent through our own connector
- The Moodle connector that gives an assistant named tools instead of a login
What the Ops Agent posted this week
Straight from our operations channel. Site names are ours or anonymised.
- Daily fleet sweep, 06:31 UTC. "Checked 31 ECS services, 13 hosts, 46 log groups. 3 issues, 1 critical." Then one line per issue, and at the end: "Read-only sweep. Nothing was changed."
- Action needed, moodle.inneall.net. "What we saw: zone SSL changed to Flexible, so the CDN originates over HTTP and the HTTPS redirect loops. Suggested action: point the HTTP listener at the healthy blue target group." Then: "Needs a human Approve. This will not run on its own."
- Recovered, Pingdom DOWN, www.inneall.ie. "Findings and evidence are in the thread." No model was called; the 75-second re-check found the site back.
- And when it was not sure: "I refused to ask for approval because the independent plan review failed closed." That line is the whole design in one sentence.
Connectors: how AI reaches our systems
An AI model is only useful to a college if it can safely use the systems the college runs. We build that access as Model Context Protocol (MCP) servers: small, named tools with their own keys and audit logs, rather than open database access.
- Moodle MCP. Containerised service on AWS giving an assistant governed access to courses, users and enrolments on a Moodle site, one tenant per key
- Student systems MCP. Four services on AWS Fargate: a portal orchestrator plus connectors for Salesforce, a student information system and an early-alert system, so one question can be answered across all three
- Management dashboard MCP. Our internal dashboard (resourcing, pipeline, management actions, timesheets) exposed to Claude so a director can ask questions and record decisions in plain language
- Website MCP. A plugin inside this Sitefinity site that lets an AI list, edit and publish pages with named keys and a server-side audit log. The pages you are reading were drafted through it
- Every connector: bearer key per service, least-privilege reads, writes only where explicitly allowed, and the destructive operations refused outright
AI writing our code
Our engineers work with AI coding agents every day, inside the same review and release process as everything else.
- Both agents above were built with AI coding tools, with 179 automated tests on the Ops Agent alone
- Each repository carries an agent briefing file, so an assistant reads the same conventions a new engineer would
- Sixteen operational skills (runbooks for our platform, written once, used by people and agents alike)
- Infrastructure as code throughout, so an agent's change is a reviewable diff, not a click in a console
- Everything ships through the same pipelines, with the same approvals, as code a person wrote
Why this matters to a college
Every Irish and UK institution is being sold AI. Very few suppliers can show it running against live systems with real permissions, real audit trails and real limits. We can, because we did it to ourselves before offering it to anyone else. The same connectors, the same approval model and the same deny lists are what we propose for your Moodle, your student record system, your CRM and your service desk.
DISCOVER
Audit and workshops
Scope of work
Integration mapping
Risk and dependency analysis
Finalised project plan
Scope of work
Integration mapping
Risk and dependency analysis
Finalised project plan
DESIGN
User experience
Concept proposals
Stakeholder reviews Design development
Final specifications
Approval to progress
Concept proposals
Stakeholder reviews Design development
Final specifications
Approval to progress
BUILD
Software development
System integration
Customisations
Content and data migration
Front end interface
System integration
Customisations
Content and data migration
Front end interface
TEST
Functional and user acceptance testing
Browser/app performance testing
Accessibility
System and security
Browser/app performance testing
Accessibility
System and security
DEPLOY
Train
Final configurations and domain go-live
Support and monitoring
Bug-fix support
Performance tuning
Final configurations and domain go-live
Support and monitoring
Bug-fix support
Performance tuning
SUPPORT
Tailored service level agreements
Responsive support
Planned maintenance
Quality control
Performance tuning
Responsive support
Planned maintenance
Quality control
Performance tuning
We love API environments
and the challenge of integration
We’ve integrated systems others refused to touch!
“Inneall’s impact on our ability to deliver reliable, scalable technology has been absolutely enormous. What sets them apart is their deep knowledge of our business, they understand our systems, our teams, and our priorities. That means we’re not dealing with a technology supplier; we’re working with a partner who genuinely cares about getting it right.”
Edward Ormonde
Head of IT, Dublin Business School
Frequently Asked Questions
Do you have preferred platforms you always recommend?
We know Moodle, Salesforce, Zoho, Sitefinity and Celcat well because they have proven themselves in colleges. We are not tied to any vendor. We start from what you need and what you already have, and we will tell you plainly if an existing platform is the right answer.
Can you help with the redesign of internal workflows?
Yes. Before we configure or build anything we sit with the people who do the work and map how it actually happens, not how the process document says it happens. We find the duplication and the friction, then design the workflow the technology will support. Better systems on broken processes do not give better outcomes.
Will off the shelf software meet all our needs?
Sometimes, rarely entirely. Established platforms are proven, maintainable and cost effective, but colleges have processes, compliance requirements and integrations that generic software does not cover out of the box. We use the platform where it fits and build the missing pieces where it does not, then connect everything so it works as one system.
How long does a typical project take?
A focused integration or workflow automation can be live in weeks. A full programme across recruitment, student records, learning and reporting usually runs six to twelve months. Every project is broken into short phases so you see working software early and can change direction while it is still cheap to do so.
Where is our data held and how is it protected?
Systems we host run in AWS in Ireland, with backups, monitoring and access controls in place, and we can also run inside your own AWS or Azure account. We sign a data processing agreement with every client. We are working towards ISO/IEC 27001 certification and can share our security practices on request.