Website ops
Agent 01 walks a page audit.
Confidential proposal · Evaluation use only
KPMC AI-Managed Digital Platform
Two Dedicated AI Agents for Website, Medical Journal & Digital Infrastructure Operations
Powered by AINNA NeuralOps
From static website maintenance to continuously managed AI-assisted digital operations.
KPMC will not simply receive a redesigned website. KPMC will receive an AI-managed digital platform operated by two dedicated AI Agents, supported by AINNA NeuralOps, running on a controlled LAMP and MySQL infrastructure.
2Dedicated AI Agents
2 / monthIndicative new digital modules
ContinuousAutomated monitoring capability
Primary demonstration
A working demonstration environment, not a production hospital site
AINNA has prepared a KPMC demonstration website to illustrate the proposed information architecture, patient journey and journal experience. It exists solely for proposal and evaluation.
Related live demos in this proposal
Journal workflow
Agent 02 drafts only after sources and review.
Two-agent handoff
Approved article becomes a website link recommendation.
Carbon compare
NeuralOps vs conventional website-ops energy.
This demonstration environment is provided exclusively for proposal and evaluation purposes. It will be removed within seven days following the formal presentation or migrated to an agreed KPMC-controlled domain or environment, where applicable, in consideration of data governance, confidentiality and PDPA requirements.
The demonstration is hosted on an AINNA domain. It is not the permanent production address. Production should use a KPMC-authorised domain such as the official hospital domain or an approved subdomain.
About AINNA
Built from real operations, then productised
AINNA develops AI-driven operational systems, NeuralOps architecture, detached systems, workflow automation and digital platforms. The technology originated from AINNA’s own operating requirements, not as a consultancy slide deck first.
Operating base
AINNA’s internal retail operations have involved approximately 30 online stores across Shopee, Lazada and TikTok commerce, with more than 80,000 SKUs and large volumes of product, marketplace, content and reporting data.
What that forced
As operations grew, AINNA built AI Agents, detached systems and NeuralOps to automate work that would otherwise remain manual, inconsistent and expensive to repeat.
What is offered to KPMC
The same operating discipline — controlled agents, human authority, least-privilege tools — applied to a hospital website, journal and LAMP environment.
Key positioning
This Is Not a Website Maintenance Contract
KPMC receives digital operations capability, not merely a website. Conventional arrangements are reactive. AINNA proposes a continuous operating model.
Conventional model
Web developerEngaged after a request exists
Manual updatesSomeone notices a problem
Change requestDeveloper logs into the server
Periodic maintenanceChange is published, then idle
Static websiteWaits for the next complaint
VS
Proposed model
KPMC ManagementSets authority, policy and approvals
AINNA NeuralOpsOrchestrates, routes and governs
AI Agent 01 + AI Agent 02Specialised digital operators
Website + Journal + Server + DatabaseOne platform, not isolated pages
Continuous monitoring & improvementRecommendations and controlled actions
AINNA is not proposing to become KPMC’s conventional webmaster. AINNA is proposing an AI-managed digital operations layer. KPMC remains the authority.
Two-agent operating model
One governance layer. Two specialised operators.
A single general-purpose agent creates mixed context and weaker audit. Separating website operations from journal intelligence improves permissions, troubleshooting and content safety.
AINNA NeuralOps
Orchestration · model routing · validation · tool permission · audit
Agent 01
KPMC Website Operations Agent
Corporate website, services, doctors, SEO, navigation, promotions, technical monitoring and website administration.
Agent 02
KPMC Journal Intelligence Agent
Journal workflow, article structure, sources, categorisation, archive, SEO and controlled AI-assisted publishing.
Linux
Apache
PHP
MySQL
File storage
Website CMS
Journal system
Logs
Scheduled tasks
Backups
How the agents share structured information
If Agent 02 publishes an approved article on diabetes screening, Agent 01 may recommend linking it from the health screening page, a relevant specialty page, the homepage article module and the internal-link map. That produces a platform, not isolated pages.
Why two agents instead of one
Agent 01 specialises in
Website, SEO, UX, public information consistency and website-related server signals.
Agent 02 specialises in
Journal, health education, references, editorial states and review cadence.
NeuralOps coordinates both. Isolation improves governance, permissions, auditability, context quality and troubleshooting.
Live demo
Two-agent handoff
Journal approved
Agent 02 notify
NeuralOps route
Agent 01 recommend links
Await KPMC review
Ready. Play to see an approved diabetes-screening article proposed for the health-screening page.
AI Agent 01
KPMC Website Operations Agent
To continuously assist with the management, organisation, optimisation and technical monitoring of KPMC’s public-facing digital presence.
Website content management
Monitor and organise hospital profile, service pages, specialist information, doctor profiles, facilities, contact and visiting information, health screening packages, corporate pages, careers, promotions, announcements, events and patient information. The agent flags potentially outdated items and requests review.
Content consistency
- Department spelling variants and title inconsistency
- Duplicate service descriptions or pages
- Expired promotional dates and old announcements
- Broken sections, missing contact details, formatting drift
SEO operations
Assists with titles, meta descriptions, headings, internal linking, sitemap consistency, broken-link detection, image alt text, content gaps, keyword coverage and duplicate metadata. This is continuous technical and content SEO. It is not a guarantee of search rankings.
User experience monitoring
Identifies broken navigation, missing information, excessively long pages, weak internal links, inconsistent buttons, missing calls to action, mobile layout problems, repeated copy and empty pages.
Link monitoring
Periodic audit of internal links, appointment links, WhatsApp links, external medical resources, social profiles, PDFs, recruitment, Qmed and contact links.
Selected technical signals
HTTP and application errors, PHP and Apache logs, disk usage, database connection failures, scheduled-task failures, availability, SSL status where accessible, redirects, missing assets, image errors, slow pages and storage growth. This is selected monitoring, not a claim of full enterprise observability.
Proposed public website experience
Professional healthcare navigation such as Home, About KPMC, Find a Doctor, Medical Services, Facilities, Health Screening, Appointments, Journal, News, Careers and Contact. The working demonstration already explores this information architecture.
Live demo · Agent 01
Website operations audit
Scan pages
Check links
SEO metadata
Flag stale promo
Queue review
Ready. This simulation does not change the live KPMC demo.
AI Agent 02
KPMC Journal & Medical Content Agent
To operate a structured healthcare journal and health-education publishing workflow. This is not an AI doctor. It is an AI-assisted publishing and knowledge-management agent.
KPMC Journal platform
The journal is a structured knowledge library, not a marketing blog. It should support categories, search, specialties, latest and featured articles, archive, publication date, author or reviewer where provided, references, related articles, reading time, medical disclaimer, tags and internal links.
Orthopaedics
O&G
Paediatrics
ENT
General medicine
Surgery
Health screening
Diabetes
Hypertension
Preventive health
Women’s health
Family health
Hospital news
Mental wellness
Categories shown are illustrative and should follow specialties KPMC actually publishes. The demonstration journal already uses a structured category model.
AI-assisted article creation
AI does not invent medical claims and publish them. The proposed workflow is:
Approved topic
Source collection
Article draft
Claim validation
Reference check
Human review
SEO structure
Publish + review cycle
Medical content guardrails
- No diagnosis of individual patients
- No personalised medical advice
- No fabricated statistics, trials, quotes or references
- No unsupported treatment or pharmaceutical claims
- No confidential patient information
- Sensitive articles require human approval
Source-based content
Priority sources: KPMC-approved internal information, Ministry of Health Malaysia, WHO, peer-reviewed literature, medical society guidance, government health information and KPMC specialist input. External material is not assumed to be legally scrapable or republishable. Use APIs, RSS, licensed sources or manual references.
Review states and metadata
Each article can carry ID, title, slug, category, tags, draft and publication dates, last reviewed date, author, reviewer, references, agent-generated flag, human-reviewed flag, SEO title, meta description and status:
Draft → AI review → Human review → Approved → Published → Scheduled review
Article refresh
Agent 02 periodically identifies articles that may need revision: older than the agreed review period, broken references, updated guidelines, expired programmes, outdated screening copy or changed specialist details. It recommends review. It does not silently change medically significant information.
Live demo · Agent 02
Controlled journal workflow
Approved topic
Collect sources
Draft
Validate claims
Human review
Ready. The agent will not publish. It stops at human review.
Beyond the front-end
AI Agents operating the operational foundation
The two agents are not chatbot widgets. They are controlled digital-operations agents that interact with selected server-level and application-level tools.
AINNA NeuralOps
Agent tool layer
Server administration tools
LAMP stack
Website + journal applications
MySQL data layer
Linux
Underlying operating environment. Agents may assist with system status, service checks, storage, file-permission audits, log inspection, scheduled tasks, backup verification, deployment checks and resource usage. Critical OS changes remain permission-controlled.
Apache
Web server layer. Monitoring may cover availability, virtual hosts, HTTP errors, redirects, access and error logs, SSL configuration, URL routing and static asset delivery. Configuration changes are controlled and logged.
PHP application layer
Primary application layer where appropriate. Agents may review error logs, deprecated-function signals, form or API failures, scheduled PHP tasks, file integrity and configuration consistency. Production code is never rewritten automatically without governance.
MySQL
Structured data for website content, doctor profiles, services, journal articles, categories, tags, references, SEO metadata, settings, audit logs and agent recommendations. Agents monitor connectivity, table health, size, failed or slow queries, duplicates, missing fields, orphans, consistency and backup status.
Database access model
Required
AI Agent → permission layer → validated tool/API → MySQL. Least privilege. No unrestricted destructive access by default.
Avoided
AI Agent → unrestricted root database credentials. Controlled tools are safer than giving an LLM raw database access.
AINNA NeuralOps
Orchestration and governance, not uncontrolled autonomy
NeuralOps is the layer that controls how AI Agents interact with the website, server, data and external models.
KPMC user
NeuralOps
Classify
Retrieve
Select model
Validate
Permit tool
Execute · verify · log
Model routing
Different tasks do not require the same model. NeuralOps may route by complexity, privacy, cost, speed, context size, reasoning and coding need. The architecture can support cloud LLMs, open-source models, local models and specialised models. This proposal is not locked to a single provider.
Detached systems
Not every task should pass through a large model. Deterministic systems handle stable work: database validation, broken-link scanning, sitemap generation, backup checks, article scheduling, metadata validation and uptime checks. AI is used where language, interpretation or decision support is required. That reduces token use, cost, latency, hallucination exposure and external-model dependency.
Knowledge hierarchy
- KPMC-approved structured database
- KPMC-approved documents
- Approved medical reference sources
- General LLM knowledge, last
Higher-confidence controlled sources take priority over generic model knowledge.
Reducing hallucination through architecture
Hallucination cannot responsibly be described as eliminated. Risk is reduced through controlled sources, retrieval, structured databases, validation rules, human approval, tool restrictions, output checking, logging, agent separation and detached systems. This proposal does not claim “zero hallucination”.
ESG and compute efficiency
Use rules, scripts, database queries, lightweight models, specialised agents, cached structured data and detached systems before escalating to a larger model. That can reduce unnecessary compute and token consumption. No carbon-reduction figure is claimed here.
Future local AI
The architecture remains compatible with future local or open-source models where commercially and technically appropriate: data control, lower API dependency, more predictable cost, specialised models and on-premise options. This does not imply that every model will run inside KPMC.
Authority and control
AI operates the system — KPMC retains authority
Agents assist with continuous operation. KPMC retains authority over medical content, corporate information, doctors’ information, pricing, promotions, clinical information, public statements and patient-related policies. AINNA manages the digital infrastructure and automation layer within agreed permissions.
Permission model
| Level | The agent may | The agent may not |
|---|---|---|
| L1 Observe | Read website status, logs, content, database metadata and SEO data | Modify anything |
| L2 Recommend | Prepare recommendations, draft content and suggested corrections | Publish without approval |
| L3 Controlled action | Update approved text, publish approved articles, update metadata, repair low-risk issues — all logged | Change medical or corporate facts without policy |
| L4 Restricted admin | Propose schema, Apache, PHP, security or server configuration changes | Execute without authorised technical approval |
Content approval matrix
Low risk
SEO metadata, broken links, formatting, image optimisation, technical fixes. May be automated under policy.
Medium risk
Service descriptions, hospital announcements, promotions. Business approval depending on policy.
High risk
Medical advice, treatment information, clinical claims, medication content. Authorised review required.
PDPA and healthcare data
The public website should minimise handling of sensitive patient medical information. If future systems process personal data, apply PDPA controls: data minimisation, consent, retention, controlled access, audit trails and secure transmission. This proposal does not create a clinical patient-data system unless separately approved.
Patient-data separation
Public website & journal
Hospital information, education content, appointments interface.
Hospital clinical systems
HIS / EMR remain isolated. Future integration only through controlled APIs and approved interfaces. Clinical databases are not exposed to the public website or to AI Agents.
Security model
Least privilege, role-based access, credential separation, secrets kept out of prompts, encrypted communications, access logging, database permission separation, production/staging separation, backup protection, rate limiting, input validation, secure uploads, PHP hardening, sanitisation, SQL-injection prevention, XSS and CSRF protection. No certification is claimed unless independently held.
Data ownership
KPMC should retain ownership of KPMC content, doctor information, medical articles, hospital data and website data generated for KPMC. AINNA owns its proprietary NeuralOps architecture, agent framework, automation technology and generic system components, subject to contract.
Digital operations
Continuous Digital Operations
Monitor
Understand
Recommend
Approve
Execute
Validate
Learn
Monitor
Change management
AI identifies an issue → recommendation → authorised review → approved change → agent executes → system validates → audit log. That loop is the operating difference versus a ticket-and-wait webmaster.
Logging and audit
Important actions record timestamp, agent ID, user, task, action, tool, data affected, previous and new value, approval status, result and error status.
Backup strategy
Production → daily application backup → database backup → encrypted off-server storage → retention policy. Recommend daily logical database backups, periodic full backup, recovery testing and backup-log monitoring. Retention periods are set with KPMC, not assumed here.
Environments and deployment
Development → staging → production. High-impact changes test in staging first. Deployment: validate → backup → staging test → approval → production → post-deploy health check.
Availability and incidents
Agents may monitor HTTP response, homepage and journal availability, MySQL connectivity, PHP and Apache errors, disk space and key pages. On error: analyse logs, classify severity, attempt only approved low-risk recovery or escalate to the AINNA technical team, then record the incident. AI cannot automatically resolve every server incident.
AINNA technical team
Agents do not remove human technical responsibility. AINNA remains responsible for maintaining and improving the architecture within the agreed service scope. Agents extend the team; they do not replace it.
AI-enhanced, not AI-dependent
If AI is unavailable, the website continues, the journal remains readable, and booking links continue to function. Critical website operations must not depend on an LLM being online.
Recommended architecture
KPMC users → security layer if applicable → Apache → PHP → MySQL (website data + journal data), alongside Agent 01, Agent 02, NeuralOps and the controlled tool layer. Optional integrations: Qmed, WhatsApp, analytics, CRM, email and other approved APIs. Unconfirmed components are labelled as recommended, not as already deployed.
Qmed
The current KPMC environment references Qmed. Proposed phases: (1) direct booking link, (2) embedded experience where technically and contractually permitted, (3) API integration if Qmed provides suitable APIs and KPMC approves. API availability is not claimed without confirmation.
AI-enhanced search — future capability
Natural-language questions such as “Which doctor should I contact for knee pain?” should guide users to relevant specialties and information. The system must not diagnose the patient.
Future management dashboard
Agent 01
Website agent · tasks · alerts
Agent 02
Drafts · reviews · publications
Server
CPU · RAM · disk
Database
Status · backup · size
Website
Uptime · broken links · SEO findings
Security
Warnings · failed logins · updates
Dashboard cards are a proposed future management interface, not a claim that a live hospital operations console is already in production for KPMC.
Analytics
Potential monitoring includes page views, popular services, doctor-profile visits, appointment CTA clicks, journal traffic, search queries, navigation paths, device mix and referrals — subject to privacy and consent requirements.
Reporting
Periodic operational reports can cover website updates, agent activity, journal activity, technical alerts, SEO findings, broken links, content recommendations, module development, security events, backup status and server health.
Business continuity
Database, file and configuration backups, recovery procedures, monitoring, agent logs and a documented manual fallback.
Implementation
Indicative roadmap — subject to scope approval
Phase 1 — Foundation
Finalise website, production environment, LAMP, MySQL, backup, Agent 01, Agent 02 and permission model.
Phase 2 — Content migration
Corporate content, services, doctors, facilities, news and journal — from approved KPMC sources only.
Phase 3 — Agent activation
Monitoring, content auditing, SEO, journal workflow, logging and approval controls.
Phase 4 — Integration
Potential Qmed, WhatsApp, analytics, CRM and email — each subject to technical and contractual confirmation.
Phase 5 — Continuous development
Approximately two approved digital modules per month, according to KPMC priorities. Not ten. Not guaranteed deliverables unless formally scoped.
Optional future agents
Agent 03 appointments/enquiry, Agent 04 marketing, Agent 05 analytics, Agent 06 internal knowledge. New agents can be added without redesigning the platform.
Two new digital modules every month
Indicative candidates, not a committed catalogue: doctor finder, appointment gateway, health screening finder, journal, medical FAQ, careers, events, promotions, specialist directory, patient and visitor guides, insurance panel directory, package comparison, corporate media centre, health calculator, newsletter, patient enquiry, WhatsApp gateway, CRM integration, analytics dashboard.
Server ownership options
A — AINNA-managed
Faster support and integrated agent management. Simpler deployment.
B — KPMC-controlled
KPMC owns hosting. Agents operate with controlled access. Stronger internal ownership.
C — Hybrid
KPMC controls production. AINNA maintains development/staging and agent systems. Often the better hospital-governance fit. No contractual choice is made in this document.
Service governance
KPMC Management → KPMC digital / marketing / IT representative → AINNA technical director / project team → AI Agents. Separate escalation paths for content, medical, technical, security and integration issues.
What AINNA is responsible for
AI Agent platform, NeuralOps, website technology, journal platform, agreed server configuration, LAMP environment, MySQL application layer, agent tooling, automation, continuous development, technical monitoring and system optimisation.
What KPMC controls
Medical policy and approval, doctor information, hospital policies, public statements, clinical content approval, corporate decisions and patient-information policies.
Commercial positioning
No price is stated here. Commercial scope depends on hosting arrangement, integration requirements, number of modules, SLA, security requirements, training, support and deployment model.
ESG · compute efficiency
Carbon print: NeuralOps vs conventional website operations
This section estimates the compute energy and CO₂e of managing a hospital website and journal — audits, drafts, SEO, link checks, logs — not the carbon of every public page view. Figures use the same layer model as the AINNA Carbon Emulator.
What is compared
Conventional: most operational tasks are sent to a large language model. NeuralOps: detached systems and rules handle scans, backups and validation; a model is used only when language or judgement is required.
Grounded factors
Grid factor default 0.74 kg CO₂e/kWh, PUE 1.4, and kWh per 1,000 requests by layer — all defaults from the AINNA Carbon Emulator. Token reduction of up to 87% is an internal benchmark on a tested language workload, not a hospital-site measurement.
What this is not
Not a certified carbon audit. Not a claim of KPMC’s actual emissions. Not a guarantee of 87% reduction on every task. Adjust the sliders; the model recalculates live.
—
— kWh
—
— kWh
—
— kg CO₂e / month
— kg / year
≤87%
Internal benchmark on tested token workload — applied only as context, not multiplied into the kg figure.
| Layer | What it represents for website ops | kWh / 1,000 tasks | Conventional share | NeuralOps share |
|---|---|---|---|---|
| GPU-heavy AI | Full LLM for every rewrite, scan summary or log read | 0.15 | 70% | 5% |
| Light AI / CPU | Short classification or title suggestion | 0.05 | 20% | 15% |
| Rule-based | Validation, metadata, schema, spelling lists | 0.01 | 8% | 20% |
| Detached system | Link crawl, sitemap, backup check, uptime probe | 0.005 | 2% | 60% |
Estimate / simulation only. Formula: tasks × layer share × (kWh per 1,000 tasks) × PUE × grid factor. Source: AINNA Carbon Emulator defaults. Change any input to see sensitivity. Do not treat the result as audited hospital ESG data.
Final message
KPMC Does Not Need Another Static Website.
KPMC can operate a continuously evolving digital platform managed by specialised AI Agents, governed by humans and supported by AINNA NeuralOps.
AINNA proposes a transition from conventional website maintenance to an AI-assisted digital operations model. Two specialised AI Agents will support KPMC’s website, medical journal, LAMP server environment and MySQL data layer while operating within defined permissions, governance controls and human approval processes.
The result is not merely a redesigned website. It is a digital operating platform designed to evolve continuously with KPMC.
The website is the interface. The journal is the knowledge platform. The LAMP server is the operational foundation. MySQL is the structured data layer. The two AI Agents are the digital operators. NeuralOps is the orchestration and governance layer. KPMC remains the authority.
