Case study: AI at Inneall

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 eight new pages and put a new home page live, with a person approving each step. This page was written and published the same way.

Platforms we run and connect for colleges

The same pattern we offer colleges: a small set of named tools,
a key per person, and a log of every call

software developer

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
Our other connectors

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 ten 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
See the result
strategic consulting

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
How we think about security

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 agent that checks our servers
AI & Intelligent automation

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
The agent that answers our service desk

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.

 how-we-do-thingshow-we-do-mobile
DISCOVER
Audit and workshops
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
BUILD
Software development
System integration
Customisations
Content and data migration
Front end interface
TEST
Functional and user acceptance testing
Browser/app performance testing
Accessibility
System and security
DEPLOY
Train
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

Discover how we think,
deliver and make an impact

View more
Case Studies

A Technology Partnership at the Heart of DBS’s Digital Ambition

Read more
AI at Inneall

Lugh: the AI agent that answers our service desk first

Read more
AI at Inneall

This website was rebuilt by an AI agent, through a connector we wrote

Read more

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.