--- name: hai-experience type: experience journey: practice description: "Experience practice skill: HAI (Human-Centred Agentic Intelligence) — design how a person, an AI agent and the systems behind it work together, step by step or stage by stage, using the three-layer HAI Journey Matrix. Use whenever a product has an assistant, copilot or agent that informs, suggests or acts for someone — paying, ordering, booking, changing an account, deciding a refund — even when the journey is not 'an AI journey'. Covers agent modes (Assistive / Advisory / Autonomous), goal failure response, human handover, multi-agent roles, memory, EU AI Act risk and sovereignty per step. Pair with any Celestial experience, design and engineering skill." --- # HAI — Human-Centred Agentic Intelligence > **Source and licence.** Based on the Human-Centred Agentic Intelligence (HAI) framework by Anandakumar Muniasamy Pothiraj (2026) (https://doi.org/10.5281/zenodo.20389202), licensed under [CC BY-NC-ND 4.0 (the framework paper)](https://creativecommons.org/licenses/by-nc-nd/4.0/). Applied to Celestial journeys by the author. HAI designs a journey in three layers at once, for every step or stage: | Layer | Answers | |---|---| | **Human** | What is the person trying to do, and how do they feel? | | **Agent** | What triggers the agent, what is it trying to achieve, how autonomous is it, and what happens when it can't? | | **System** | What data, infrastructure, protocols, memory and governance make that behaviour reliable? | Source: Anandakumar Muniasamy Pothiraj, *Human-Centred Agentic Intelligence (HAI): A Three-Layer Framework for Designing Human-Agent-System Journeys*, May 2026, [doi:10.5281/zenodo.20389202](https://doi.org/10.5281/zenodo.20389202). This skill applies that framework to Celestial journeys. ## Two modes, one Agent and System layer | | User Journey matrix (step-based) | Customer Journey matrix (stage-based) | |---|---|---| | Unit | One task step: "complete checkout" | One lifecycle stage: Awareness, Consideration, Purchase, Onboarding, Retention, Advocacy | | Time | Minutes to hours | Days to years | | Human layer | Step-level goal, user task, user action, user emotion, user pain points | Stage-level outcome, customer task, customer action, customer emotion, customer pain points | | Agent focus | Precision: exact triggers and tool calls | Progression: trust and autonomy growing across stages | | Measures | Task completion, tool accuracy, latency | Stage conversion, trust over time, lifetime value | Celestial `journeyType: user` and `workflow` journeys use the step-based matrix; `customer` journeys can use either. When both exist, **the stage's agent mode is the ceiling for every step inside it**. ## Agent modes | Mode | The agent | The person | |---|---|---| | **Assistive** | Provides information when asked; takes no action | Chooses every action | | **Advisory** | Suggests or prepares; waits for a decision | Decides — accepts, changes or rejects | | **Autonomous** | Acts without explicit approval, inside guardrails | Can override or undo after the action | Rules: 1. **Autonomy follows trust and safety.** Start Assistive for new people, early steps and high-risk decisions; Advisory for configuration, decision support and personalisation; Autonomous only for routine steps and established relationships. 2. **System capability validates autonomy.** A step may run Autonomous only if its System layer can support it (fresh data, undo, logging). 3. **Mode floor.** If any agent in a step's pipeline runs at a lower mode than the step's, the whole step runs at the lowest. 4. **Severity means a person.** Money, health data and legal obligations escalate to a human immediately when anything goes wrong. 5. **The person stays in control.** They can override, question or opt out of agent actions at every step and stage. A step with no agent involvement records its mode as `none`. ## The step (or stage) record Fill these for every step where an agent takes part. Each cell is a plain sentence — the behaviour itself, not a label. **Human layer.** Step-level goal · task · action · emotion · pain points. **Agent layer.** - **Trigger / cue:** the event or signal that makes the agent act. - **Agent mode:** Assistive, Advisory or Autonomous (and why). - **Agent goal:** what it is trying to achieve here. - **Agent actions:** the messages, UI affordances, automation or recommendations. - **Agent tone:** how it speaks at this moment, matched to the person's emotion. - **Agent type:** generalist or vertical; single or orchestrated. - **Multi-agent handoff:** in normal flow, which agents run, in what order. - **Goal failure response:** what it does when it can't meet its goal (see below). - **Failure handover trigger:** when control leaves AI mode, to whom, and with what context. **System layer.** - **Data needs** and **data freshness & SLA**. - **Physical / infrastructure:** latency, resilience, on-device or cloud. - **Compliance & governance:** privacy, regulatory and organisational constraints, including telling people they are dealing with an agent. - **Protocol:** MCP (agent ↔ tool), A2A (agent ↔ agent), AG-UI (agent ↔ interface). - **Agent memory:** short-term, episodic or procedural, and what carries to the next step. - **Sovereignty boundary:** data residency, compute residency, model provenance, cross-border flow, accountable jurisdiction — or "Non-sovereign" with a reason. - **Regulatory & sovereignty classification:** EU AI Act risk tier, sector rules, data protection regime, sovereignty regime — per step, not per journey. In a reusable Celestial experience skill, record the Human and Agent layers and the System layer's data needs, memory tier and risk classification. Product-specific System cells (sovereignty boundary, protocols, infrastructure SLAs) belong in the product's own spec. ## Goal failure response Every agent step has a failure path, not only a happy path. Name the likely failure types: | Type | Example | Response | |---|---|---| | Ambiguous input | "Book me something for Thursday" | Ask a clarifying question | | Data unavailable | Stock service times out | Retry or fall back; say so | | Constraint violation | Action would breach a privacy rule | Reduce scope; explain why | | Low confidence | Classification below threshold | Human review before acting | | Partial completion | Booked, but calendar sync failed | Retry the sub-task; show what's done | | Full task failure | Payment provider down; fraud block | Hand over — can't be solved in AI mode | | Goal drift | Cheapest flight, ignoring "direct only" | Re-align to what the person asked | By mode: - **Assistive:** surface the failure plainly, give the reason without jargon, offer alternatives (another source, a manual path, a contact), log it. - **Advisory:** state low confidence instead of hiding it, show ranked alternatives, let the person reject and re-ask, drop to Assistive if still unsure after a retry, log the decision. - **Autonomous:** before acting — abort, tell the person, ask for guidance; mid-action — stop, show the partial state, offer undo; after — tell them at once, offer reversal; undetected — drop to Advisory and find the cause. Always: say what was done, what failed and the current state, then log it. ## Human handover Hand over when: more than two retries fail · confidence stays below threshold · the SLA window passes · a regulatory block is hit · **the person asks for a human (immediately, no retry)** · money, health or legal stakes are involved · two or more agents in the pipeline have already failed. Pass the receiving person a **handover context package**: the person's goal in their own words · the journey step or stage · what was tried and failed, and why · what is already done · the retry history · emotional signals · relevant memory · active compliance flags · a suggested next action (advice only). In the interface: announce the transfer before it happens, show what has been resolved and what remains, and let the person keep using the agent read-only alongside the human. ## Checklist for an agent step - [ ] Mode set and justified; no step above its stage's ceiling; Autonomous only where the System layer supports it - [ ] Trigger, goal and actions written as concrete behaviour - [ ] The person is told they are dealing with an agent, and agent-made content is identifiable - [ ] Advisory steps: the person decides; nothing is committed without them - [ ] Autonomous steps: override and undo stated; the person is told after each action - [ ] Goal failure response names the likely failure types and the response for this mode - [ ] Failure handover trigger names the condition, the receiver and the context package; "ask for a person" always works - [ ] Money, health or legal steps escalate to a person on failure - [ ] Data needs, memory tier and risk classification recorded; memory can be viewed, edited and deleted ## Further detail - [references/matrix.md](references/matrix.md): the blank step and stage matrices and a filled example. - [references/failure-and-handover.md](references/failure-and-handover.md): failure states, triggers and the context package in full. - [references/multi-agent-and-memory.md](references/multi-agent-and-memory.md): agent roles, the trust chain, orchestration patterns and memory tiers. - [references/governance-and-sovereignty.md](references/governance-and-sovereignty.md): EU AI Act risk classes, NIST alignment, the seven sovereignty types and the sovereignty boundary. - [references/measurement.md](references/measurement.md): metrics by layer, the golden dataset and the link from metrics to handover triggers. ## Reference files These files sit next to this SKILL.md in the download and the repository; their full text follows here so this file works on its own. ### references/matrix.md ### HAI Journey Matrix Copy one column per step (User Journey) or per stage (Customer Journey). Fill every row; write "None at this step" or "Non-sovereign — reason" rather than leaving a cell blank. #### User Journey matrix (step-based) | Dimension | Step 1 | Step 2 | Step n | |---|---|---|---| | **HUMAN LAYER** | | | | | Step-level goal | | | | | User task | | | | | User action | | | | | User emotion | | | | | User pain points | | | | | **AGENT LAYER** | | | | | Trigger / cue | | | | | Agent mode | | | | | Agent goal | | | | | Agent actions | | | | | Agent tone | | | | | Agent type | | | | | Multi-agent handoff (normal flow) | | | | | Goal failure response (failure behaviour) | | | | | Failure handover trigger (escalation threshold) | | | | | **SYSTEM LAYER** | | | | | Data layer needs | | | | | Data freshness & SLA | | | | | Physical / infrastructure | | | | | Compliance & governance | | | | | Protocol layer | | | | | Agent memory requirements | | | | | Sovereignty boundary | | | | | Regulatory & sovereignty classification | | | | #### Customer Journey matrix (stage-based) The same Agent and System rows. The Human layer becomes: stage-level outcome · customer task · customer action · customer emotion · customer pain points. Typical stages: Awareness · Consideration · Purchase · Onboarding · Retention · Advocacy. Typical memory by stage: Awareness short-term only · Consideration episodic activates · Purchase episodic + procedural · Retention all three · Advocacy procedural essential. #### Example — "Amount and confirm" in send money (step-based) | Dimension | Step 4: Amount and confirm | |---|---| | Step-level goal | Send the right amount to the right person, once | | User task | Check the payment and approve it | | User action | Reads the summary, taps Approve, uses face or passcode | | User emotion | Careful, slightly anxious about mistakes and scams | | User pain points | Fear of sending to the wrong account; codes that expire | | Trigger / cue | Payee checked and purpose chosen; the person asked the assistant to pay | | Agent mode | Advisory — money moves only on the person's decision | | Agent goal | Make the payment unmistakable before it is approved | | Agent actions | Prepares the payment; shows payee, name-check result, amount, fee and reference in large text; marks what it filled in; steps back while the person authenticates | | Agent tone | Calm, plain, unhurried | | Agent type | Vertical payments agent; single | | Multi-agent handoff | Payments agent → fraud-check service → payment rail | | Goal failure response | Over the daily limit: say the limit and when it resets, keep the amount. Fraud hold: say it is held, why in plain words, and what happens next. Rail down: full task failure — hand over | | Failure handover trigger | Fraud block, rail failure or the person asks → bank support, with the context package; immediately, because money is involved | | Data layer needs | Payee details, name-check result, balance, daily limit, fee table | | Data freshness & SLA | Real time; balance and limit under 1 s | | Physical / infrastructure | Approval round trip under 2 s; retries are idempotent so nothing is sent twice | | Compliance & governance | Strong customer authentication by the person; the assistant never sees codes; audit log of who prepared and who approved | | Protocol layer | MCP to the payments and fraud APIs | | Agent memory | Short-term: payee and amount from earlier steps; episodic: saved payees | | Sovereignty boundary | Account data stays in the bank's jurisdiction; inference in-region; no cross-border transfer of account numbers; accountable entity: the bank | | Regulatory & sovereignty classification | Payments regulation (authentication, payee check); data protection; AI interaction transparency; not high-risk under the EU AI Act | ### references/failure-and-handover.md ### Goal failure response and handover Failure handling is the same in both matrix modes. Without it, agents fail silently, retry for ever, or escalate with no context. #### Seven failure types | Type | Meaning | Recoverability | |---|---|---| | Ambiguous input | Intent can't be determined with enough confidence | Recoverable — ask | | Data unavailability | Data missing, stale or unreachable | Conditionally — retry or fall back | | Constraint violation | The action would breach a compliance or system boundary | Partially — reduce scope | | Low confidence output | A result exists but is below threshold | Recoverable — human review first | | Partial completion | Some sub-tasks done, others not | Partially — retry the sub-task | | Full task failure | Can't be done whatever the retries | Not in AI mode — hand over | | Goal drift | The literal task is done but the intent is missed | Recoverable — re-align | #### Response by mode **Assistive.** Surface the failure explicitly (never an empty result). Give the reason without jargon. Offer alternatives: another source, a manual path, a contact. Log the type, trigger and time. No escalation needed — the person is in control. **Advisory.** Declare low confidence rather than withholding the suggestion. Give the suggestion with its context. Show ranked alternatives when confidence is split. Allow rejection and re-asking with new context. Drop to Assistive if still unsure after a retry. Log the suggestion, confidence and the person's decision. **Autonomous.** | State | Meaning | Response | |---|---|---| | Pre-action | Detected before acting | Abort, tell the person, ask for guidance | | Mid-action | Fails part-way through | Stop the remaining steps, show the partial state, offer undo | | Post-action | Done, but the outcome misses the goal | Tell the person at once, offer reversal, log for review | | Silent | Not detected until someone notices | Drop to Advisory, find the root cause | Then: report exactly what was done, what failed and the current state → offer undo → degrade to Advisory → hand over if unrecoverable → audit log entry. #### Five states the person experiences | State | Agent | Person | |---|---|---| | Active | Normal operation | Normal interaction | | Uncertain | Asks, or discloses uncertainty | Asked for input, or sees an uncertainty signal | | Degraded | Retries with a fallback; mode drops | Slower, or less capable | | Escalating | Prepares the handover context package | Told about the transfer | | Resolved (by handler) | Original agent moves to monitoring | Continuity with the new handler | #### Handover triggers | Trigger | Example | Goes to | |---|---|---| | Retry limit | More than 2 retries without resolution | Specialist agent → human | | Confidence threshold | Still below threshold after retry | Specialist agent or human | | Timeout | No resolution within the SLA | Human, plus a system alert | | Regulatory block | Action would break a compliance rule | Compliance reviewer, immediately | | User-initiated | The person asks for a person | Human, immediately, no retry | | Severity | Money, health data or legal obligation | Human, immediately | | Cascade prevention | 2+ agents in the pipeline already failed | Human, immediately | #### Handover context package 1. The person's goal, in their own words — always 2. The journey step or stage — always 3. Failure summary: what was tried, what failed, why — always 4. Partial completion state — when partly done 5. Retry history, in order, with outcomes — always 6. Emotional signal: frustration, urgency, confusion — human handovers 7. Memory snapshot: relevant episodic and procedural memory — always 8. Compliance flags — regulated contexts 9. Recommended next action — always, as advice only #### Handover in the interface - Announce before transferring: who they're being connected to, and that the context goes with them. - Show what has been resolved and what remains. - Let the person keep using the agent read-only alongside the human. ### references/multi-agent-and-memory.md ### Multi-agent systems and memory #### One step, many agents A matrix column is a phase the person sees, not one agent call. Behind it may be a pipeline; the person sees one coherent experience and the Agent layer documents what runs beneath. | Role | Does | Visible to the person | Modes | Accountable for | |---|---|---|---|---| | Orchestrator | Breaks down the goal, delegates, combines results, runs handover logic | Partly | Advisory to Autonomous | The overall outcome | | Specialist | Does one sub-task in its domain | Usually not | Autonomous within its domain | Its sub-task | | Verifier | Checks other agents' output against quality, compliance or accuracy thresholds | No | Autonomous | Quality; flags failures to the orchestrator | | Human liaison | Connects the pipeline to people; builds context packages; routes escalations | During handover | Assistive | The handover | Ultimate accountability stays with the deploying organisation. In EU AI Act high-risk pipelines every agent keeps its own audit trail: when it was active, input, output, confidence, governance flags. ##### What the person sees | | Routine | Mode escalation | Human handover | |---|---|---|---| | Step-based | One coherent step | Told the agent needs their input; the step pauses | A summary of what the step achieved and what remains | | Stage-based | A consistent experience across touchpoints | Told when a recommendation needs their confirmation | A lifecycle summary; the human is briefed on the history | ##### Trust chain - **Context fidelity:** every agent-to-agent handoff carries the full handover context package. - **Confidence propagation:** combined confidence decides whether the orchestrator acts autonomously or escalates. - **Mode floor:** the pipeline runs at the lowest mode of any agent in it. - **Cascade prevention:** two consecutive agent failures → hand to a human; no further delegation. ##### Orchestration patterns | Pattern | Shape | On failure | Use for | |---|---|---|---| | Sequential | A → B | B gets the failure flag and partial state | Linear work with clear dependencies | | Parallel | A and B together; orchestrator combines | Continue with a partial result, or escalate | Independent sub-tasks | | Hierarchical | A manager delegates and resolves conflicts | Re-delegate or escalate | Complex work with competing resources | | Event-driven | Agents wake on signals | A missed signal trips a timeout monitor | Asynchronous, long-running work | | Verifier loop | Specialist → verifier → back if rejected | Two rejections → human review | High-stakes output | #### Memory | Tier | Where | Lasts | Step-based use | Stage-based use | |---|---|---|---|---| | Short-term (working) | Context window | The session | Context carried between steps | Context within one touchpoint | | Episodic | Vector store | Across sessions | Preferences, past settings, history | History across all stages | | Procedural | Learned patterns | Across sessions, evolving | How this person likes to work | Contact preferences, autonomy tolerance, communication style | - Step-based: say what context step n needs from step n−1, and what carries across sessions. - Stage-based: say which tier each stage needs and when episodic and procedural memory switch on. - Both: what the agent knows in a step must match what the stage allows. - Always: memory follows data-protection retention and deletion rules, and people can view, edit and delete what the agent remembers. ### references/governance-and-sovereignty.md ### Governance and sovereignty #### Classify risk per step, not per journey | EU AI Act category | Examples | Design obligations | |---|---|---| | Prohibited | Subliminal manipulation, social scoring, some biometrics | No design is acceptable | | High-risk | Employment, education, healthcare, law enforcement, critical infrastructure | Risk management, human oversight, automatic logging, conformity assessment | | General-purpose AI | Foundation models | Transparency, copyright, systemic-risk duties for the most capable | | Minimal / no risk | Most recommendations and content generation | No mandatory duties; transparency is best practice | Risk can differ by stage and step: a recommendation at Awareness may be minimal risk while an automated contract renewal at Retention may fall under automated-decision rules. Record the class on each step. Telling people they are dealing with an agent sits in the regulatory classification and the compliance row, so every agent step must say how it is disclosed. #### NIST AI RMF alignment | NIST function | HAI dimension | |---|---| | Govern | Compliance & governance constraints | | Map | Regulatory & sovereignty classification | | Measure | Data freshness & SLA; the measurement framework | | Manage | Agent mode limits; goal failure response; failure handover trigger | #### Sovereignty is a design-time decision Runtime controls (residency rules, regional endpoints) can be added later. Who decides what, on whose infrastructure, under whose law and with whose accountability has to be decided at design time, in the matrix. ##### Seven sovereignty types | Type | Covers | Where it lives in HAI | |---|---|---| | Data | Where data is stored and processed, and whose law applies | Data needs; sovereignty boundary | | Compute | Where inference, training and fine-tuning run | Physical / infrastructure; sovereignty boundary | | Model | Model provenance, licensing and ownership | Agent type; sovereignty boundary | | Regulatory | Which legal regime governs the deployment | Regulatory & sovereignty classification | | Operational | Who operates and controls the system | Compliance & governance | | Linguistic & cultural | Native language and cultural fit | Agent tone; user emotion | | Security & trust | Independent identity, authentication, audit, observability | Protocol layer; compliance & governance | ##### Sovereignty boundary (per step or stage) 1. Data residency jurisdiction, and any cross-border transfer mechanism 2. Compute residency: in-jurisdiction, sovereign cloud, a named zone, or cross-border allowed 3. Model provenance limits: which model families, providers or training data are allowed 4. Cross-border flow: allow or deny for each data type 5. Accountable jurisdiction: the legal entity and authority answerable for failures With no constraints, write "Non-sovereign" and a reason. Writing it down is itself the audit record. Three-layer separation lets sovereignty differ by layer: a foreign foundation model (Agent) with in-jurisdiction inference and storage (System) and native-language experience (Human). ##### Regimes to record per step AI-specific risk regime · sector regime (finance, health, public sector, defence…) · data protection regime · sovereignty regime (national requirements, procurement, critical infrastructure, export control). Record each that applies; recording that none applies shows it was considered. ### references/measurement.md ### Measurement The same three-layer structure, with targets that differ by mode. #### Step-based (User Journey) **Human layer** | Metric | Target | |---|---| | Task completion (reported by people) | > 85% | | Step abandonment | < 10% | | Override / fallback rate | Watch for drift; high means Advisory is miscalibrated | | Agent output kept without major edits | > 70% | | Time to verify a handover | Less than doing it by hand, or the friction outweighs the value | **Agent layer** | Metric | Target | |---|---| | Goals resolved without a human | Hand over if it drops by more than 10% | | Tool selection accuracy | > 90% | | Invented tool arguments | < 2% | | Plan adherence | Deviation above 15% signals unstable reasoning | | Reasoning coherence | ≥ 4 / 5 | | Goal failures by type | Separates systemic from one-off failures | | Mode degradation frequency | High means the thresholds are too aggressive | **System layer** | Metric | Target | |---|---| | Data freshness within SLA | 100% on Autonomous steps | | End-to-end latency | Within the step's infrastructure requirement | | Cost per successful task | Track against baseline | | Protocol error rate | < 1% | | Audit logging coverage | 100% for EU AI Act high-risk | #### Stage-based (Customer Journey) — in addition Stage conversion · NPS at the start and end of each stage · lifetime-value impact against a cohort · trust score rising stage over stage · cross-stage memory accuracy > 85% · channel consistency > 90%. #### Golden dataset Before launch, build 20–50 representative examples with expected outcomes, correct tool calls and known failure cases — step-level tasks for step-based journeys, lifecycle scenarios with stage-boundary edge cases for stage-based ones. #### KPIs Specific, measurable through logging (if it can't be logged it can't be a KPI), achievable on current infrastructure, tied to a matrix dimension or failure threshold, and time-bound: weekly operational, monthly step-based, quarterly stage-based. #### Metrics behind each handover trigger | Trigger | Live metric | Alert | |---|---|---| | Retries without resolution | Failures by type — retry count | Orchestration log counter | | Confidence below threshold | Reasoning coherence, tool accuracy | Real-time model-graded scorer | | Timeout | End-to-end latency | Trace alert | | Regulatory block | Audit coverage, regulatory flag count | Governance alert | | Person asks for a human | Override / fallback rate | Interface event log | | Stage conversion drops > 10% | Stage conversion | Weekly regression | | Task completion drops > 10% | Agent-measured completion | Weekly regression against the golden dataset |