Back to ideas
Guidelight - an adaptive, channel-agnostic support companion
Everyone|4mo ago
TechnologyMinimally testedFundingCollaborationJust take it
The Idea
Guidelight helps people complete complex online tasks by meeting them on the channels they already use (SMS, WhatsApp, Facebook Messenger, RCS, email, web chat, and voice/IVR). It blends step-by-step guidance with agentic AI that can reason over forms, documents, and rules, then hands off to a human adviser if/when needed.
A pluggable SDK and MCP-compatible tool stack make it straightforward to add new services, connectors, and channels without rebuilding the core.
Perhaps a transitional schema keep integrations stable as service patterns and models evolve.
The Problem
People often have a device but still struggle to finish critical online journeys. Reasons include unfamiliar interfaces, inaccessible language, low confidence, patchy data, and the friction of switching between channels or apps. Services also miss early warning signs of frustration or drop-off, creating costly failure demand.
Benefits
For people: help arrives where they already are, in their preferred language and medium (text or voice); clear micro-steps; fast human fallback.
For services: higher completion rates, lower abandonment, fewer repeat contacts, clearer insight into friction points.
For communities: a reusable SDK that local partners can extend.
For policymakers/designers: privacy-preserving analytics that highlight where underlying services need simplifying.
How It Could Work
1) Go where people are (true omnichannel):
Support for SMS, WhatsApp, Facebook Messenger, RCS, email, web chat, and voice (including touch-tone and speech).
Single conversation state across channels, so a user can start on WhatsApp, continue by SMS, and finish over a phone call without losing context.
Low-data modes and offline-first patterns (e.g., queued messages, small payloads).
2) Agentic AI with MCP, SDKs, and tools:
MCP servers expose tools (identity checks, eligibility rules, appointments, document capture, form filling) behind a stable protocol.
GuideLight SDK (client and server) standardises channel adapters, authentication, session state, and logging.
Task-centric agents break problems into micro-steps, ask clarifying questions, call tools via MCP, and verify results before continuing.
3) Deep mapping of services and connectors:
Unified service schema (OpenReferral-style) to represent organisations, locations, criteria, evidence required, costs, and opening hours.
API connectors for directories, eligibility checkers, appointment systems, document stores, and case-management platforms.
Built-in migrations so connectors keep working as the schema evolves.
Which minimum fields unlock real value? How do we signal capability gaps and graceful fallbacks?
Curation workflow so local partners can propose edits, add missing services, and flag outdated entries.
4) Sentiment & drop-off prediction with a “rip-cord”:
Multimodal sentiment from text and voice (lexical cues, hesitation, prosody, speaking rate, interruptions).
Frustration/abandonment scoring detects when confidence is slipping or a journey is looping.
Rip-cord action: immediate switch to a human adviser via warm transfer (phone/webchat), or fast booking for a call-back; share the minimal context needed with consent.
Micro-prompts (“Shall I get a person to help now?”) to keep user agency front and centre.
5) Model adaptability from day one
A Model Abstraction Layer to switch providers per task (classification, extraction, reasoning) based on cost, latency, and data residency.
Start with managed models; progressively route high-volume, low-risk tasks (sentiment, intent, entity extraction) to small, self-hosted models.
Redaction and private-by-default routes for sensitive contexts.
6) Journey intelligence & improvement loop:
Privacy-preserving analytics show where users get stuck, which steps trigger the rip-cord, and what fixes improve completion.
7) Safety, privacy, and inclusion by design:
Clear consent flows, data minimisation, and per-connector access controls.
Local language support, plain-English/“easy read” modes, screen-reader friendliness, and interpretable AI prompts.
Human-in-the-loop for sensitive decisions; transparent explanations for automated steps.
Challenges
Turning access into completion in a world where services are increasingly “digital-first”, while many people face layered barriers:
1) Digital and data exclusion
Inconsistent connectivity & data poverty: pay-as-you-go data, shared devices, or patchy signal make rich web journeys fragile.
Device churn & capability gaps: older phones, small screens, and limited storage break modern form flows and document upload steps.
Channel lock-in: some services only support web or app pathways, ignoring SMS/WhatsApp or voice, forcing people off their habitual channels.
2) Literacy and language barriers
Reading burden: long, jargon-heavy pages and PDFs exceed many people’s reading level and attention span.
Form complexity: dense questions, hidden validation rules, and unfamiliar evidence terms lead to errors and abandonment.
Language & communication needs: non-native speakers, neurodivergent users, screen-reader users, and people with low confidence need simpler copy, pacing, and multimodal options (text + voice).
3) Data and identity hurdles
Proof requirements: identity, address, or income evidence is often scattered, hard to digitise, or time-limited.
Security friction: multi-factor steps (codes, authenticator apps) don’t translate well to shared devices or low-signal contexts.
Inflexible back-ends: legacy portals expect perfect inputs in one sitting; pause/resume or assisted completion is rare.
4) “Digital-first” by default, not by design
Service drift: new online flows launch faster than guidance, leaving front-line staff and directories out of date.
One-size journeys: rigid funnels assume confidence, bandwidth.
Late support: systems detect failure only after drop-off, not when frustration begins.
What's Stopping This
Well, there is lots here to still explore.
- Connector availability & agreements: Some directories and back-office systems lack open APIs or require data-sharing agreements. Are websites set up for agent access?
- Model reliability & bias: Sentiment from diverse dialects and accents needs careful tuning and continuous evaluation.
- Operational capacity for handoffs: Human adviser partners must have the staffing and rotas to accept warm transfers.
- Usage by target users: will this actually work for the people we think it would work with?
- Schema design and adoption: designing an adaptable schema for services for now and into the future will be needed. Adoption of that will need to be thought through. A transitional schema might be useful.
All of this needs researching and exploring. A minimal version could be scoped on one or two channels with minimal services.