Skip to content

KAIA — Kiwire AI Assistance ​

The assistant that checks the tenant on a schedule and tells you what it found.

What KAIA does and where it stops A loop of five steps. The heartbeat cron runs every fifteen minutes and visits each tenant every six, twelve or twenty-four hours. It runs thirteen detectors through a read-only database user, with every query checked before it runs. The findings are narrated to admins and summarised in a daily review. From those, KAIA proposes actions drawn only from the fixed action catalogue, with no free-form action. An admin clicks Apply; the permission is checked again and the change is audited as kaia.action. The change lands on the tenant's own records, which the next heartbeat sees. A dashed boundary encloses the proposal and apply steps: KAIA never touches admins, roles, secrets, credentials, payments, the licence, RADIUS, MFA, connectors, and never deletes, and there is no autopilot. Heartbeatcron every 15 mineach 6, 12 or 24 hkaia:heartbeat1 RUNSDetectors13 checksread-only DB userqueries checked2 FINDSFindingsnarrated to adminsdaily reviewReviewer3 PROPOSESProposalsfixed catalogue onlynothing free-formvalidate()4 A PERSONApplyan admin clickspermission checkedkaia.action5 APPLIED TO THE TENANT'S OWN RECORDS — THE NEXT HEARTBEAT SEES THE CHANGEInside the dashed boundary, never: admins · roles · secrets · credentials · payments · licenceRADIUS · MFA · connectors · deletes — and no autopilot: nothing runs until a person clicks Apply
KAIA proposes; a person applies. Everything it can change is a small, named entry in the catalogue, applied the same way an admin would do it by hand so the audit trail sees it. The never list is enforced in the catalogue itself and pinned by KaiaActionsNeverTest, so adding an action that crosses it fails the test suite, not a code review.

What KAIA watches ​

Every heartbeat runs 13 detectors over the tenant's own data: controllers that have gone silent during their normal active hours, a zone or the tenant as a whole gone quiet on logins, spikes in login failures and their reject reasons, scheduled jobs that have stopped running or started failing, licence headroom (monthly logins, Passpoint users, device count against plan limits, and licence expiry), report aggregation falling behind, zone configuration problems (like a forced profile that no longer points at anything), session or bandwidth patterns that look off against the site's own recent baseline, campaign health, voucher stock running low, the platform RADIUS/portal certificate approaching expiry, mismatches against a connected PMS feed (the feed going quiet, or a checked-in guest who's never logged onto Wi-Fi), and the tenant's own AI token budget approaching its cap.

Findings and the weekly review ​

Each run reconciles what the detectors just found against what's already open, sorting everything into new, escalated, reopened, cleared, or unchanged. It only narrates the result in plain language — using whichever AI credential the tenant has resolved — when something actually changed, or when the last narrated digest is more than a day old; a tenant with no AI key configured still gets accurate findings, just without the prose wrapped around them.

Separately, once a week by default (an admin can choose every 1, 2, 3 or 7 days), a tenant review looks at the deployment as a whole rather than at individual findings. It builds a factual snapshot of the tenant — unused or limitless profiles, zones with unusually high failure rates, controllers that have never carried traffic, voucher stock, licence headroom, general guest experience — and asks the model to turn any real gaps in that snapshot into up to five prioritized, plain-language suggestions. KAIA is shown the suggestions already open and does not raise the same issue again in different words; if a reworded duplicate slips through, the older card is closed as superseded by the newer one. A suggestion that's dismissed stays off the list for 30 days before KAIA is allowed to raise it again, and a suggestion closes itself automatically once the gap it named is no longer true.

Narration and the review use the tenant's monthly AI allowance. When a tenant on Synchroweb's shared key has used 80% of it, the review waits for next month; at 90%, findings are still raised but without narration, so what is left stays available for the admins' own questions.

Every Monday morning, each admin of a tenant with KAIA switched on gets one notification listing the findings and suggestions still waiting on someone. Acknowledge a finding, and mark a suggestion Done or Not relevant, to take it off that list.

If KAIA is switched off for a tenant, findings from earlier runs are closed after a day rather than left showing as open; they come back on the first run after KAIA is switched on again, if still true.

Proposed actions and Apply ​

Beyond the automatic heartbeat, an admin can chat with KAIA directly on its page. It answers questions with a read-only lookup over a fixed set of reporting views (one bounded SELECT at a time — no comments, variables, or multiple statements allowed), by reading the captive-portal and RADIUS log lines for one device or one controller over the last day (account names masked) — the step-by-step record behind "the page does not load" or "logged in but no internet" — or by proposing a single action from a small, fixed catalog: change a profile's speed (in Mbps), quota, session or idle limits — applied the same way the profile form saves them, so the change reaches the controllers; switch a zone on or off; assign a published journey to a zone; set or clear a zone's forced profile; pause, resume, or extend a campaign's end date; set a controller's opening hours, or switch its Wi-Fi on or off (switching off disconnects everyone online on it); reset a guest or voucher account's password; disconnect a guest's device; let a device skip the captive portal on a MikroTik controller; create voucher codes or move a voucher's expiry date; or acknowledge, snooze, mark won't-fix, or dismiss a finding or suggestion.

KAIA never applies anything on its own. Every proposal is shown to the admin as a plain-language summary of exactly what would change, and only takes effect on a deliberate click of Apply — which re-checks that the admin has the specific permission the action needs, runs the change through Kiwire's normal model layer so it shows up in the audit trail exactly like a hand-made edit, and additionally logs its own kaia.action audit entry. For a password reset, the new password is generated at the moment of Apply, shown once to the admin who clicked it, and never written anywhere KAIA or the audit trail can read it back.

The KAIA page ​

  • Status line: whether KAIA is watching, when it last checked and when it checks next. Check now runs a check straight away. Settings holds the schedule and, under About this assistant, the model and recent usage.
  • Today's briefing: the latest summary as a headline and a few points, with a coloured edge and a label for the worst open problem: red for critical, amber for warnings, grey when everything open is snoozed or acknowledged, green when all is clear. The buttons take you to the problems or ask KAIA about the briefing.
  • Ask KAIA: the wide main column. On an empty conversation it offers a few starter questions.
  • Needs your attention: four tiles (Act now, Look this week, Improvements, Checks) and the tabs Problems, Improvements, Snoozed, Resolved and Activity. The tile counts are of open problems only; snoozed and acknowledged ones are counted separately. Several problems from the same check are grouped into one line, which Show expands.
  • Open on a problem or suggestion shows it in the list's place: KAIA's read of it, the plain facts, its buttons, and questions you can ask about it with one click. It also pins the item to the chat, so follow-up questions stay about it. Back or Esc returns to the list.
  • Apply on a suggestion makes the change it carries. When the daily review can name one exact change (a profile's limits, a zone's journey, forced profile or on/off switch, a campaign's status or end date, a controller's opening hours or Wi-Fi on/off), the card says Apply will: and what changes, from what to what. Apply checks the change again against how things are now and needs the same permission as making it by hand. The suggestion then closes as applied, and the change appears in the audit trail like a hand-made edit. If someone already made the change by hand, the suggestion closes itself the next time the page loads.
  • Do it with KAIA on a suggestion without a ready change asks KAIA to propose the exact change in the chat, with an Apply button there.

Asking KAIA ​

KAIA answers in the words you see in the admin: zones, controllers, profiles and journeys by name, and where to make a change by its menu path. It does not show internal field names, ids or queries. It names only menus and settings that exist in the admin; when it is not sure Kiwire can do something, it says so and points you to this documentation rather than guessing.

Under most answers KAIA offers up to three questions you are likely to ask next, under You could ask next. Click one to ask it. When KAIA offers to make a change and nothing has been proposed yet, quick Yes / No buttons appear instead.

In a long conversation KAIA answers your newest message. Earlier topics, including the summary written when a conversation is compacted, are kept as background and are not picked up again unless you refer back to them.

Each answer can take a limited number of lookups. If a broad question uses them all, KAIA says so and asks you to narrow it down, for example to one zone, one controller or one time window. Asking again more narrowly works better than raising any limit in Settings.

Guest-support actions ​

Four actions exist because they are what support is asked for most, and each does exactly what the matching page does — nothing more:

  • Disconnect a guest's device. Give KAIA the account username or the device's MAC address. It only proposes when that guest is actually online, and Apply sends the disconnect to the controller the session is on. The session then clears once the controller confirms it ended — the Active Sessions list is what the controller reports, so it is not edited by hand. If the controller does not answer, Apply says so plainly rather than pretending: the guest is still online, and the reason is spelled out — the router is not reachable from Kiwire on the CoA port, or RADIUS incoming is not enabled on it, or the RADIUS secret on the router differs from the one saved for that controller, or the router refused. Nothing is recorded as done in that case.
  • Let a device skip the captive portal. The bypass list lives on the controller itself, not in Kiwire, so KAIA reads it live before it proposes anything (and can tell you whether a specific MAC is already on it — the first thing to check when "my device is bypassed but still sees the portal"). Adding an entry works on MikroTik controllers only; an entry stays until somebody removes it on the Bypass Devices page — KAIA never removes one.
  • Create voucher codes. One exact code, or a prefix and a quantity of up to 500 (larger batches are made on the Vouchers page), on an active profile, with an optional expiry date in your own time zone, an optional zone restriction and a note. Generated batches appear on the Vouchers page within a minute, marked as created through KAIA by the admin who clicked Apply.
  • Move a voucher's expiry date. Give the exact code and the new date, up to three years out.

KAIA needs the exact username, code or MAC address for these — its own views show them masked, so it will ask you for them.

What KAIA will never touch ​

The action catalog is deliberately narrow and pinned by its own test: KAIA can never touch admins, roles, secrets, credentials, payments, the licence, RADIUS, MFA, or connectors, and it can never delete anything. There's no free-form action it can invent and no autopilot mode — every entry in the catalog is a small, named, permission-gated change to one of the tenant's own records, and every one of them still needs a human to click Apply.

Heartbeat timing ​

A scheduled kaia:heartbeat job dispatches every 15 minutes, but that's just how often KAIA checks whether a tenant is due — each tenant only runs a full detection pass once its own configured interval has elapsed, a choice of 6, 12, or 24 hours (12 by default), with a few minutes of built-in slack so a 6-hour cadence checked every 15 minutes doesn't slowly drift later each cycle. KAIA has to be switched on for the tenant, and the platform has to make it available to that tenant's plan, before the page shows anything but an off-state; detection itself runs on schedule regardless of whether an AI credential is configured, but narration and the daily review both need one to actually produce their write-up.

Last updated:

Kiwire platform documentation