Yorimi

An evidence-first AI character-presence Agent for AI + Entertainment.
Persona-aware conversation, useful micro-actions, session continuity, and inspectable Agent Run evidence.

English · 简体中文 · Website Preview · Local Runbook · Agent Card · Evaluation Matrix

_{Concept campaign visual — not a product screenshot, deployed UI, or hardware evidence.}

Website Preview status — checked 2026-08-04: the website is reachable but predates the current Wave 3 Agent Run build and still carries the predecessor deployment name, Compagnon Éveil. Use the local Runbook for current evaluation until redeployment is complete. Some restricted or campus networks may require a VPN/network that can reach Vercel.

中文摘要： Yorimi 参加 S3 AI+文娱赛道。本轮交付是一个可运行的角色陪伴 Agent、8 个代码级 Runtime Skills、Web Demo、机器可读的 Agent Run 证据及完整评测材料。查看完整中文版。

Yorimi — Judge at a Glance

Field	Submission
Competition track	AI + Entertainment / AI+文娱赛道（confirmed）
Product	Adaptive AI character presence for digital IP, companionship, study, and everyday routines
Repository role	The inspectable software evaluation build for a broader character platform and optional desktop-presence product
Shipped in this repository	Runnable orchestrating Agent, 8 Runtime Skills, Web UI, same-process session continuity, transparent fallback, tests, and Demo script
Primary judged path	Companion setup → contextual conversation → optional micro-action/check-in → follow-up → inspectable Agent Run
Not claimed as shipped	Creator Studio, production persistent memory, real-time hardware bridge, user-validation, retention, paid-conversion, or revenue results
Detailed submission	Wave 3 package

Yorimi turns a character from passive content into an adaptive presence. The current message remains the highest-priority input; persona, tone, use case, recent context, and session memory shape how the Agent responds without replacing the answer the user actually needs.

Study companionship is the most reproducible evaluation scenario in this repository. The scenario tests whether a character follows its configured persona, responds to the present situation, offers an optional next action, and continues the interaction with visible execution evidence.

Evaluation Case — Dimension by Dimension

Evaluation dimension	Current evidence or execution design	Confidence-building next gate
Track and timing	A focused AI + Entertainment thesis: turn original or authorized characters from passive content into adaptive, ongoing interaction	Validate repeat use with external character and companion users
Differentiation	Persona-aware response → optional micro-action → check-in → session continuity → inspectable Agent Run → desktop-presence extension	Measure persona consistency and screen-versus-device preference
Product maturity	End-to-end Web/API loop, companion setup, eight Runtime Skills, Agent evidence, fallback handling, assets, Runbook, and a fresh-checkout test record	Deploy the current Wave 3 build and run moderated external sessions
Technical depth	Code-level Skill routing, strict structured output, repair and quality guards, bounded session lifecycle, runtime disclosure, and deterministic evaluation	Complete a verified live-model run and publish latency/quality results
Commercial viability	Staged software, authorized-content, Creator/IP, event, and hardware models with explicit activation gates; no revenue, orders, confirmed exhibitions, or pilots claimed	Prove repeat use, creator commitment, price-qualified intent, and delivery economics in sequence
Team	Wang Siyu leads Marketing & Business; Martina leads Product, AI Engineering & Hardware Integration; the predecessor team also has UCWS Singapore Top 20 proof	Add specialist partners only when creator, legal, event, or manufacturing gates activate
Documentation	English-first entry, full Chinese mirror, Runbook, Agent Card, Skills Catalog, Specs matrix, test evidence, safety boundaries, and issue remediation	Keep every public claim tied to a reproducible file, response, test, or external document

Yorimi does not rely on a self-assigned score. It provides a direct path from each judging dimension to inspectable evidence and a stated next proof gate.

Website Preview

_{Current Website Preview landing screen: choose the Study Companion path and create a companion. The deployment still uses the predecessor name Compagnon Éveil; evaluate the latest Wave 3 Agent Run locally until Vercel is updated.}

What Is Actually Delivered

Deliverable	Observable result
Orchestrating Agent	POST /api/chat returns an answer, inferred intent, mode, actions, memory update, trace, runtime flags, and one agent_run
Runtime Skill Registry	A request-specific subset is selected from a Registry of 8 bounded Skills and injected into the runtime plan
Interactive product loop	Setup → chat → action or teaching support → check-in → follow-up within one session
Agent evidence in the UI	The Wave 3 UI surfaces selected Skills, statuses, evaluation checks, runtime source, and fallback state
Transparent degradation	Missing or failed model access produces an explicitly labeled deterministic fallback, never a fake live-model claim
Reproducible evaluation	Runbook, fixed Demo prompts, Specs matrix, automated tests, limitations, and issue-remediation evidence are included

Evidence-Backed Technical Architecture

Yorimi is more than a prompt wrapper. The model is the language-reasoning engine; the repository runtime is the control and evidence plane. Local code owns request validation, latest-message routing, mode resolution, Skill selection, session context, response-schema definition, output normalization, live-path correction, fallback disclosure, deterministic checks, and rendering.

+---------------------------------------------------------------+
|                     YORIMI WEB EXPERIENCE                     |
| setup | character/object identity | chat/voice | check-in     |
| pseudo-3D presence | answer-first UI | Agent Run panel        |
+-------------------------------+-------------------------------+
                                | POST /api/chat
                                | latest message + companion context
                                v
+---------------------------------------------------------------+
|                    HTTP + CONTRACT BOUNDARY                   |
| host/CORS/method checks | JSON/request validation | session   |
+-------------------------------+-------------------------------+
                                v
+---------------------------------------------------------------+
|                DETERMINISTIC AGENT CONTROL PLANE              |
| latest-turn intent -> effective mode -> executable Skill plan |
| persona_adaptation + request specialist + memory_continuity   |
+----------------------+------------------------+---------------+
                       | live path              | degraded path
                       v                        v
+--------------------------------+   +--------------------------+
| OpenAI Responses API           |   | Deterministic fallback   |
| Skill/context injection        |   | normalized API response  |
| strict structured JSON         |   | fallback_used = true     |
| first live generation          |   | runtime_source = "mock" |
+----------------+---------------+   +-------------+------------+
                 v                                 |
+------------------------------------------------+ |
| LIVE NORMALIZATION + RUNTIME QUALITY GUARDS   | |
| normalize -> repair decision -> optional retry | |
| re-normalize -> runtime guards -> visible form | |
+-----------------------------+------------------+ |
                              |                    |
                              +----------+---------+
                                         v
+---------------------------------------------------------------+
|          COMMON VISIBLE FORMAT + AGENT EVIDENCE PLANE        |
| run ID | objective | selected Skills | 9 checks | trace       |
| runtime source | fallback | per-Skill outcome-evaluation      |
+----------------------+------------------------+---------------+
                       |                        |
                       v                        v
+-------------------------------+   +---------------------------+
| SAME-PROCESS TTL MEMORY       |   | ANSWER / ACTIONS / TTS/UI |
| goals, plans, check-ins       |   | local Node + Vercel       |
| ephemeral; non-shared on      |   | adapters share handlers   |
| serverless deployments        |   | but not process memory    |
+-------------------------------+   +---------------------------+

Why this is technically distinctive

1. Latest-message-first control: routing gives the latest message precedence, while intent, mode, topic, and outcome checks flag detectable output misalignment.
2. Executable Skill orchestration: code selects a per-turn plan and injects those instructions before generation; Skills are not labels added after the answer.
3. Structured output plus runtime guards: strict-schema generation is followed by normalization and live-path runtime guards; deterministic fallback keeps the same normalized API response shape and remains explicitly labeled.
4. Targeted repair: generic planning language in the initial normalized response can trigger one replacement generation, which is normalized again before runtime guards.
5. Inspectable run evidence: every successful server-side chat turn returns a run ID, selected Skills, nine evaluation checks, trace steps, runtime source, and fallback state.
6. Transparent degradation: missing or failed model access keeps the contract testable while clearly reporting deterministic fallback instead of fake live AI.
7. Bounded continuity: recent goals, plans, check-ins, settings, and turns are retained with TTL, capacity, and reset controls inside the current process; serverless invocations do not share or guarantee this memory.
8. Shared deployment logic: the local Node server and thin Vercel adapters delegate to the same request handlers rather than maintaining two separate runtimes.

Core implementation: request handlers, orchestrator, Skill Registry, OpenAI adapter, runtime schema, fallback engine, session store, and Wave 3 tests.

Product differentiation and defensibility

Character Context
    -> Contextual Answer
    -> Optional Micro-action
    -> Check-in
    -> Session Continuity
    -> Inspectable Agent Run
    -> Optional Desktop-Presence Extension

Layer	Current differentiator	How defensibility can compound after validation
Character integrity	Persona, tone, role, object identity, and current intent enter each turn	Creator-authored profiles, authorized lore, governance rules, and measured consistency
From talk to action	The main answer can lead into a relevant optional action and check-in	Outcome-informed routines and character-specific interaction design
Trust	Agent Run and fallback state make run evidence inspectable	Comparable quality telemetry, regression sets, and creator-facing controls
Continuity	Bounded session memory supports follow-up without overruling the latest turn	User-governed durable memory only after consent, deletion, and retention design
Presence	Physical desktop media demonstrates the intended extension beyond screen-only chat	A device-state protocol and reliable bridge only after presence advantage is measured

Hardware Presence GIF

The animated repository asset below explicitly shows the current physical-form proof alongside the software evaluation build.

_{Physical desktop-presence proof. The current media demonstrates form and preset states; it does not claim a shipped real-time Agent-to-device bridge or manufacturing readiness.}

The current system is one orchestrating Agent with eight code-integrated Skills. It does not claim eight autonomous agents, an Agents SDK handoff system, durable vector memory, a real-time 3D engine, or production hardware control.

Eight Runtime Skills

Skill ID	User-facing responsibility
persona_adaptation	Applies character identity, tone, role, use case, and object context without overriding the latest request
memory_continuity	Uses recent history and session memory while keeping the current message authoritative
concept_guidance	Explains the current subject with a compact example and an understanding check
task_planning	Converts a concrete goal into relevant, time-bounded next steps
emotional_support	Acknowledges the user state without diagnosis, then offers one low-pressure relevant action
quiz_practice	Runs focused one-question-at-a-time practice
routine_progress	Handles routines and Done / Partly done / Stuck check-ins
companion_presence	Provides natural character interaction without forcing every turn into a task template

Repository and local verification:

• GET /api/skills exposes the public Registry and evaluation checks.
• POST /api/chat returns selected Skills and derived outcome evaluations inside agent_run.
• The response trace contains routing, selected-Skill outcome-evaluation, and Agent evaluation steps.
• Skills Catalog maps every Skill to triggers, code, output, and acceptance tests.

Machine-Readable Agent Evidence

A successful response includes a compact structure like:

{
  "answer": "A direct, context-aware response",
  "intent": "emotional_support",
  "mode": "Encourage Mode",
  "runtime_source": "openai",
  "fallback_used": false,
  "agent_run": {
    "run_id": "unique-per-turn",
    "inferred_intent": "emotional_support",
    "skills": [
      { "id": "persona_adaptation", "status": "complete" },
      { "id": "memory_continuity", "status": "complete" },
      { "id": "emotional_support", "status": "complete" }
    ],
    "evaluation": {
      "status": "passed"
    }
  }
}

The structure is evidence that routing and checks ran. It does not, by itself, prove factual correctness, long-term retention, or commercial value.

Three-Minute Evaluation Path

1. For the current Wave 3 repository build, follow the local Runbook. The public preview currently lacks this build's Agent evidence.
2. Open http://127.0.0.1:3017/nextstep-companion.html.
3. Create a companion with a study role, a tone, and an object identity such as Coffee Cup.
4. Send: I have a finance quiz tomorrow, but I am tired and stuck.
5. Confirm that the answer acknowledges the state, remains about the finance quiz, and offers a relevant next action.
6. Open the Agent Run panel and inspect intent, mode, selected Skills, checks, runtime_source, and fallback_used.
7. Send: Give me the concept of algebra. Confirm explanation, example, and understanding check.
8. Send a short follow-up or choose I got stuck. Confirm that the same session uses the recent topic and produces a smaller next step.

Full script: Demo and Evidence.

Claims → Evidence Map

Claim	Implementation and evidence	Honest boundary
A runnable Agent exists	orchestrator, handlers, commit add03c6	Live generation requires a valid server-side model configuration and network
8 Skills affect execution	Skill Registry, /api/skills, agent_run, commit add03c6	They are bounded capabilities inside one Agent
Agent Run is visible	Wave 3 Web UI, commit a51cb74	UI labels do not replace inspecting the actual response
Same-process session continuity exists	sessionStore.js, Agent Card, tests	Memory is not durable across processes, accounts, or devices
Fallback is transparent	Runtime flags, mock engine, guards, Wave 3 tests	Fallback cannot prove live-model conversation quality
A reproducible Runbook and test suite are provided	submission package, commit 9827221	Live-model verification remains a separate step
Historical plans are separated	Wave 1 Archive, commit 73e919a	Archived roadmaps are not current deliverables
A hardware presence proof exists	hardware GIF, hardware video	Media does not prove real-time Agent control, reliability, or manufacturing readiness
Feedback was incorporated	Issue remediation, commit d0e3df7	Closing feedback does not validate long-term product hypotheses

Business Model & Execution

Commercial status: Yorimi currently proves a runnable Wave 3 Agent and a physical desktop-presence concept. The revenue layers, creator program, showcase route, and preorder-readiness framework below are staged plans with explicit validation gates—not claims of existing revenue, confirmed exhibitions, pilots, or orders.

Commercial thesis

Yorimi enters as a software-first AI character-presence Agent and can expand into a creator-enabled character platform with an optional desktop layer. The commercial thesis is not “more chatbot minutes”; it is to make character interaction repeatable: respond in identity, help the user take a relevant next step, preserve continuity, disclose how the Agent ran, and travel across Web, authorized content, events, and a desktop surface.

This sequencing is capital-disciplined:

1. Software must prove repeat value before hardware absorbs capital.
2. Original and authorized IP can create distribution, identity, and digital-content economics.
3. Every expansion must pass observable user, creator, safety, and unit-economics gates.

Revenue stack

Layer	Payer and paid value	Revenue mechanism	Activation condition
Core Web Agent	Individuals use the base companion loop	Free acquisition and product-learning layer	Runnable prototype exists
Companion membership	If the gated features ship, repeat users would receive premium characters, voice options, and user-controlled memory	Monthly or annual subscription	Repeat use is demonstrated and promised features are shipped
Authorized character content	After rights and delivery gates pass, fans could receive licensed skins, voices, expressions, and story interactions	One-time purchase or creator revenue share	Rights chain, moderation, and delivery are defined
Creator/IP services	Original or authorized IP owners could configure interactive characters through a narrow pilot	Pilot/project fee, SaaS, revenue share, or a tested hybrid	Creator discovery produces a committed narrow pilot
Exhibition and brand activation	Events, cultural venues, or partners could deploy a configured Agent plus presence display	Project fee, rental, sponsorship, or campaign package	A reliable event kit and measurement flow exist
Limited desktop edition	Qualified users could obtain an optional small-batch presence device only after all gates pass	One-time sale plus authorized content	Demand, engineering, compliance, support, and delivery gates all pass

No price, conversion, preorder, or revenue number is presented as a result. Pricing becomes a public promise only after price-disclosed tests and deliverable features exist.

Go-to-market system

Community / creator / showcase discovery
                  |
                  v
Campaign QR -> Companion setup -> useful first response
                  |
                  v
Action or check-in -> follow-up -> completed companion loop
                  |
        +---------+----------+
        |                    |
        v                    v
repeat-use cohort     qualified creator / event lead
        |                    |
        +---------+----------+
                  v
membership / pilot / price-qualified waitlist experiment
                  |
                  v
documented go / revise / stop decision

1. Prove the loop: recruit external character, study, and work users for setup → conversation → action/check-in → follow-up.
2. Build with rights holders: interview original or authorized IP owners before implementing Creator Studio controls.
3. Use showcases as validation laboratories: compare screen-only and device-assisted experiences and measure consented funnel behavior through campaign-specific QR links.
4. Launch one narrow authorized experience: prove configuration, governance, repeat use, and support before attempting a broad marketplace.
5. Scale hardware only after software demand: the desktop device remains an optional high-presence surface, not a dependency for adoption.

Singapore and Shanghai target showcase path

• Singapore target: bilingual product testing, campus/innovation access, creator discovery, and a compact Web-plus-desktop Demo. Measure completed loops, qualified waitlist intent, creator leads, and screen/device preference.
• Shanghai target: Chinese-language ACGN and character/IP discovery, creator partnership conversations, and manufacturing/service feasibility research.
• Status: these are target validation markets. No specific exhibition, date, booth, invitation, or partnership is claimed as confirmed until a verifiable organizer page, invitation, or agreement is linked.

Preorder readiness gates

The following are proposed go/no-go thresholds, not current results:

Gate	Evidence required before advancing
1. Core demand	30–50 external target users; at least 70% complete the core loop; at least 25% opt into and complete a seven-day return session
2. Presence advantage	At least 20 balanced screen/device comparisons; at least 60% prefer the device-assisted condition; no critical usability failure remains
3. Price-qualified interest	At least 100 qualified waitlist entries see the price first; at least 15% actively request a reservation at that disclosed range
4. Delivery feasibility	At least two supplier quotations plus documented BOM, assembly, packaging, payment, support, return cost, and positive pilot contribution margin
5. Reliability and compliance	Repeatable setup, connection-loss recovery, thermal/power checks, certification path, warranty/refund terms, and authorized content process
6. Capped paid pilot	Only after Gates 1–5: a small refundable-deposit batch with a public cap, milestones, refund process, and stop-sale trigger

Until these gates pass, Yorimi will collect non-binding waitlist or reservation intent rather than describe interest as an order.

Execution roadmap

Milestone	Product and evidence	Commercial output	Go/no-go decision
Current baseline	Stabilize the Wave 3 Agent, publish the current build, preserve tests and Agent evidence	Research script, funnel events, creator interview guide, showcase kit	Reproducible product baseline
External validation	Run 30–50 user sessions and 3–5 creator interviews	Positioning, repeat-use, package, governance, and willingness-to-continue evidence	Select one primary user wedge and one creator wedge
Singapore showcase target	Bilingual Web/desktop Demo and campaign measurement	User/creator leads plus screen/device comparison	Decide whether presence adds measurable value
Shanghai showcase target	Chinese flow and authorized original-IP examples	Creator/IP demand and delivery-ecosystem evidence	Select a candidate creator pilot and hardware feasibility scope
Narrow pilot	Build only validated creator controls, governed memory, or bridge functions	One authorized-character pilot	Require repeat use, partner commitment, and support-cost evidence
Limited launch	Membership/content first; hardware only after every gate	Capped refundable pilot instead of open-ended presales	Verify delivery, contribution, reliability, and trust

Metrics that drive decisions

The north-star metric is weekly completed companion loops: an activated user receives a relevant response and reaches an action, check-in, or meaningful follow-up. Chat volume alone is not success.

Area	Decision metrics
Activation	Setup completion, first useful response, completed loop, time to first value
Agent quality	Agent Run pass rate, topic relevance, persona consistency, fallback rate, latency, failed-turn reason
Retention	D1/D7 return, completed loops per active user, repeated use of the same companion
Creator demand	Qualified interviews, pilot commitment, configuration time, required governance controls
Showcase funnel	Demo starts, loop completion, QR conversion, creator leads, screen/device preference
Commercial intent	Price-qualified waitlist rate, reservation intent, membership concept choice
Hardware	Uptime, setup failure, BOM, contribution margin, defect, return, and support rate
Trust	Memory consent/deletion success, unauthorized-IP reports, fallback-disclosure accuracy

Founder execution is deliberately narrow: Wang Siyu, Co-founder — Marketing & Business, owns discovery, creator/IP relationships, positioning, pricing tests, and showcase funnels; Martina, Co-founder — Product, AI Engineering & Hardware Integration, owns product delivery, Agent Runtime, evaluation, deployment reliability, privacy controls, and bridge feasibility. Industrial design, manufacturing, certification, legal/IP, and event production become partner workstreams only when their corresponding gates activate.

Run Locally

Requirements: Git and Node.js 18 or newer.

git clone https://www.synnovator.com/mart/Yorimi.git
cd Yorimi
npm ci
cp .env.example .env
npm run dev

PowerShell equivalent:

git clone https://www.synnovator.com/mart/Yorimi.git
cd Yorimi
npm ci
Copy-Item .env.example .env
npm run dev

Open:

http://127.0.0.1:3017/nextstep-companion.html

For live AI, configure the untracked .env:

OPENAI_API_KEY=your_key_here
USE_MOCK_AI=false

Without a key, the UI and API contract remain testable through the labeled fallback. The standalone UI uses CDN-hosted frontend dependencies, so a complete local render still needs network access or cached assets. Never commit real credentials.

Verification

Run the complete non-live suite:

npm run test:all

This executes:

• test:agents
• test:wave3
• test:vercel
• test:mart
• test:api
• test:d

Fresh-checkout verification: tested content candidate aac834b, 2026-08-04, Node.js v24.14.0. A clean local clone completed npm ci, then all six suites above passed. The temporary verification clone was removed afterward. The later verification-record commit changes documentation metadata only.

With a valid OPENAI_API_KEY, run the separate live check:

npm run test:openai

test:openai is intentionally not part of test:all. A green non-live suite does not prove live-model response quality. Full evaluation combines automation, the Specs matrix, and the human Demo path.

Live-runtime verification is not currently marked as passed. The local environment has no evaluation OPENAI_API_KEY; the public preview reported openai_configured: true but returned fallback_used: true and runtime_source: "mock" during the 2026-08-04 check. This completed the verification step and proved transparent degradation, but it is not evidence of live-model quality.

Community Feedback Incorporated

This README and the Wave 3 package were rewritten after community feedback. The remediation distinguishes implemented work from documentation, plans, and still-unvalidated hypotheses.

Issue	Feedback	Result
#4	Architecture, memory, privacy, hardware, competitor positioning, and evidence	Detailed remediation reply; closed
#5	Duplicate Wave 2 review	Evidence index added; kept closed and not double-counted
#6	Positioning, business model, user validation, and team scope	Detailed remediation reply; closed

Detailed mapping: Issue Remediation.

Scope, Safety, and Truthful Boundaries

Shipped

• One orchestrating Agent with 8 code-integrated Runtime Skills.
• Answer-first Web interaction, optional actions, teaching, quiz, check-in, and same-process session continuity.
• Machine-readable Agent Run, runtime checks, trace, and fallback disclosure.
• Local run path, tests, Demo script, evaluation matrix, and community-review evidence.
• Hardware media showing a desktop presence proof.

Not yet validated or shipped

• Production persistent memory, user accounts, or cross-device recall.
• Creator Studio or creator pilot results.
• Real-time Web/App-to-device control.
• Hardware reliability, certification, bill of materials, manufacturing, orders, or after-sales operations.
• Published user scale, retention, paid conversion, revenue, or statistically evaluated character consistency.
• A complete Wave 3 screen recording of the current Agent flow.
• General visual understanding from uploaded images.

Yorimi is not a substitute for therapy, medical care, crisis intervention, or professional advice. Do not enter secrets or sensitive identity information into the current prototype. Full policy: Limitations and Safety.

Founders and Early Proof

• Wang Siyu（王斯昱） — Co-founder, Marketing & Business. ESSEC Business School Global BBA student and ESSEC Excellence Scholarship recipient; leads market research, positioning, creator/IP relationships, go-to-market, and commercial strategy.
• Martina Lee — Co-founder, Product, AI Engineering & Hardware Integration. Nanyang Technological University Physics PhD student; leads product delivery, Agent Runtime, AI engineering, technical implementation, and hardware-integration feasibility.

Yorimi evolved from Compagnon Éveil. The predecessor project team, which included Wang Siyu and Martina Lee, was selected as a UCWS Singapore Hackathon 2026 Top 20 Finalist. This is early project recognition, not proof that the current Wave 3 implementation has passed every competition criterion.

Submission Documents

Document	Purpose
Wave 3 Overview	Stage, deliverables, and evaluator entry points
Agent Card	Agent inputs, outputs, API, architecture, and boundaries
Runbook	Clean clone, configuration, execution, tests, and troubleshooting
Skills Catalog	Triggers, code anchors, output, and acceptance criteria for all 8 Skills
Specs Matrix	Executable acceptance criteria and verification evidence
Demo and Evidence	Fixed prompts, three-minute path, and evidence index
Cross-review	Community feedback record
Limitations and Safety	Unshipped work, data governance, safety, IP, and prototype limits
Issue Remediation	Concrete response to Issues #4, #5, and #6