Insights / Case studies
Case study inneall.ie
This website was rebuilt by an AI agent.
In October 2026 we handed an AI agent the keys to inneall.ie through a connector we wrote ourselves. It reviewed every page, fixed bugs we had missed, built eleven new pages and put a new home page live, with a person approving each step. This page was written and published the same way.

The same pattern we offer colleges: a small set of named tools, a key per person, and a log of every call
What the agent did in one working day.
The brief was plain: review every page, bring the whole site to one message, build the new offer pages and case studies, then move the new home page live once everything else was ready.
- Read every public page and every blog post, and reported what was wrong before changing anything
- Rewrote seven existing pages to one message and pointed every “Learn more” at the right place
- Built eleven new pages by duplicating a template page and rewriting its blocks, each published at a hidden URL for review first
- Fixed two blog posts: a heading that had been pasted in as plain text and a word with a missing space
- Published two new articles to the blog and moved the approved draft onto the live home page, block by block
What it found that we had missed.
The most useful part was not the writing. It was that the agent read the rendered HTML of every page, not just the content in the CMS, and compared the two.
- The “Read more” links in a block shared across most pages pointed at our staging server, not the live site
- The shared FAQ block rendered with a broken first question that could not be opened
- A page in the site tree was marked visible but returned a 404
- A hidden section still held placeholder text that would have gone live if anyone had published that page
- The connector itself could not edit shared blocks or page titles, so the agent wrote the change list for the next version
The connector.
Our website runs on Progress Sitefinity. We wrote a small plugin that runs inside the site and speaks the Model Context Protocol, the open standard that lets AI tools call named functions. It is about 1,900 lines of C# and exposes seventeen tools.
- List, read, duplicate, publish and delete pages; read and update the content blocks on a page
- List, create, update, publish and delete news and blog posts
- A named access key for every person using it, so the audit log says who changed what
- Any property whose name contains password, secret, token or key is refused outright
- Deleting a page needs an explicit confirmation and the page’s exact URL; the home page cannot be deleted or unpublished at all
Guard rails.
An agent with write access to a public website needs limits that are enforced by the connector, not just promised in a prompt.
- The live home page was off limits until the draft had been reviewed at a separate hidden URL
- Every edit was made as an unpublished draft, then published in one deliberate step
- Nothing was deleted or unpublished during the rebuild
- Every call is logged on the server against the person’s key
- The agent was told to stop and report on any failure rather than retry blindly
What this means for a college website.
Most college websites run on a CMS with years of accumulated pages, broken links and copy nobody has read since it was written. The same connector pattern lets an AI agent audit the whole site, propose fixes as drafts and leave a human to approve them, without anyone handing over a CMS login. We build these connectors for Sitefinity, Moodle, Salesforce and our own student systems, and we run them on our own site first.
A person stayed in the loop.
The agent did the work. A director set the direction, reviewed each draft page at its hidden URL, corrected the tone where it drifted, and gave the go-ahead for the home page.
- “Don’t make it sound too AI” was a real instruction, and it changed the copy
- “We can’t claim ISO 27001 yet” removed a claim before it went live
- Client names were removed from every example unless the client had agreed
- The review took minutes per page, not days
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.
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.
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.
More case studies
Keep reading.
A technology partnership at the heart of DBS's digital ambition
How Dublin Business School and Inneall grew a long-term technology partnership.
Read the case study →Replacing dispersed student data with a student information system
How Chevron College replaced scattered student spreadsheets with a student information system, connected to a new CRM and LMS.
Read the case study →Taking BodySlims global
How BodySlims and Inneall built a mobile-first product partnership for global growth, with an iOS and Android app.
Read the case study →Talk to us
Want a partnership like this?
We are happy to start with a short call and no sales deck. Or begin with a fixed-price review of your Moodle, integrations or student systems.
Integrators for specialised education and CRM platforms
- Moodle
- Salesforce
- Zoho
- HubSpot
- Sitefinity
- Celcat
- Microsoft 365
- AWS
The same pattern we offer colleges: a small set of named tools,
a key per person, and a log of every call

The connector
Our website runs on Progress Sitefinity. We wrote a small plugin that runs inside the site and speaks the Model Context Protocol, the open standard that lets AI tools call named functions. It is about 1,900 lines of C# and exposes seventeen tools.
- List, read, duplicate, publish and delete pages; read and update the content blocks on a page
- List, create, update, publish and delete news and blog posts
- A named access key for every person using it, so the audit log says who changed what
- Any property whose name contains password, secret, token or key is refused outright
- Deleting a page needs an explicit confirmation and the page’s exact URL; the home page cannot be deleted or unpublished at all
What the agent did in one working day
The brief was plain: review every page, bring the whole site to one message, build the new offer pages and case studies, then move the new home page live once everything else was ready.
- Read every public page and every blog post, and reported what was wrong before changing anything
- Rewrote seven existing pages to one message and pointed every “Learn more” at the right place
- Built eleven new pages by duplicating a template page and rewriting its blocks, each published at a hidden URL for review first
- Fixed two blog posts: a heading that had been pasted in as plain text and a word with a missing space
- Published two new articles to the blog and moved the approved draft onto the live home page, block by block


Guard rails
An agent with write access to a public website needs limits that are enforced by the connector, not just promised in a prompt.
- The live home page was off limits until the draft had been reviewed at a separate hidden URL
- Every edit was made as an unpublished draft, then published in one deliberate step
- Nothing was deleted or unpublished during the rebuild
- Every call is logged on the server against the person’s key
- The agent was told to stop and report on any failure rather than retry blindly
What it found that we had missed
The most useful part was not the writing. It was that the agent read the rendered HTML of every page, not just the content in the CMS, and compared the two.
- The “Read more” links in a block shared across most pages pointed at our staging server, not the live site
- The shared FAQ block rendered with a broken first question that could not be opened
- A page in the site tree was marked visible but returned a 404
- A hidden section still held placeholder text that would have gone live if anyone had published that page
- The connector itself could not edit shared blocks or page titles, so the agent wrote the change list for the next version
A person stayed in the loop
The agent did the work. A director set the direction, reviewed each draft page at its hidden URL, corrected the tone where it drifted, and gave the go-ahead for the home page.
- “Don’t make it sound too AI” was a real instruction, and it changed the copy
- “We can’t claim ISO 27001 yet” removed a claim before it went live
- Client names were removed from every example unless the client had agreed
- The review took minutes per page, not days
What this means for a college website
Most college websites run on a CMS with years of accumulated pages, broken links and copy nobody has read since it was written. The same connector pattern lets an AI agent audit the whole site, propose fixes as drafts and leave a human to approve them, without anyone handing over a CMS login. We build these connectors for Sitefinity, Moodle, Salesforce and our own student systems, and we run them on our own site first.


DISCOVER
Scope of work
Integration mapping
Risk and dependency analysis
Finalised project plan
DESIGN
Concept proposals
Stakeholder reviews
Design development
Final specifications
Approval to progress
BUILD
System integration
Customisations
Content and data migration
Front end interface
TEST
Browser/app performance testing
Accessibility
System and security
DEPLOY
Final configuration and domain go-live
Hypercare in the first weeks
Bug-fix support
Handover to support
SUPPORT
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
